curl converter

About this tool

Paste a curl command and it is parsed into a method, URL, headers, body and Basic auth, then that same request is rendered as JavaScript fetch, axios, Python requests and C# HttpClient code. Or start from the "Build a request" form and get the curl command plus all four code snippets from what you typed. Both directions run through the same generators, so the output is consistent whichever way round you use it.

Nothing is sent anywhere. This tool does not run curl and does not make the request — it is a text transformation only, entirely client-side.

How it works

Parsing a pasted command is a hand-written shell-style tokeniser: it understands single quotes, double quotes with backslash escapes, a bare backslash escaping the next character, and a backslash immediately before a line break joining two lines — the standard bash/POSIX conventions curl documentation and browser "Copy as cURL" features both use. It does not understand PowerShell or Windows cmd quoting (caret line continuation, doubled ""), which is a different, incompatible syntax — see Known limitations below.

When a command uses -d/--data with no -H "Content-Type: ..." of its own, curl silently sends application/x-www-form-urlencoded on the wire. This page adds that same header rather than leaving it out, so the generated code actually reproduces what curl would send — that default is only added on the parse side, since "Build a request" describes a request directly rather than modelling curl's -d behaviour, and never invents a header you did not type.

-G/--get together with -d or --data-urlencode is handled the way curl itself handles it: the data is moved onto the URL as a query string and the method stays GET, rather than being sent as a body.

A body is only rendered as a JSON object literal (rather than a plain string) when the effective Content-Type is application/json and the body parses as valid JSON — both conditions, not just one, so a JSON-shaped body sent with a different content type is not silently reinterpreted.

Two real gotchas the generated code avoids

fetch's body must be a string

Passing a plain object as fetch's body does not send JSON — it sends the literal text [object Object], a genuinely common mistake. This page's fetch output always calls JSON.stringify(...) on a JSON body. axios is different: it accepts a plain object for data and serialises it for you, so the axios output passes the object directly, unstringified — matching what each library actually expects, not the same shape for both.

C#'s Content-Type does not go on Headers

Calling request.Headers.Add("Content-Type", ...) on an HttpRequestMessage throws InvalidOperationException at runtime — content headers belong to the content object, not the request. This page's C# output sets it through StringContent's own media-type parameter instead, and leaves it out of the general Headers.Add loop, so the generated code runs rather than throwing on the first request with a body.

Common questions

Why did a Content-Type header appear that I didn't type?

Only when parsing a command that uses -d/--data/--data-urlencode with no content type of its own — see "How it works" above. It reflects curl's real default, not a guess.

Why wasn't my -F/--form command converted?

-F builds a multipart/form-data body, which needs a random boundary string and per-part headers this page does not generate. Rather than produce code that looks plausible but sends the wrong bytes, the field names are listed in Notes and no code is produced for them. See Known limitations.

Does this run curl, or make the request?

No. It reads the text of the command and rewrites it — the same as it reads a form and writes curl. No fetch, no proxy, no server involved.

Basic auth — why does the code differ per language?

Each one uses whatever that ecosystem considers idiomatic: curl gets -u user:pass, axios gets its own auth: { username, password } config field, Python requests gets the auth=(user, pass) tuple shorthand, and C# gets an AuthenticationHeaderValue. Only fetch has no built-in option, so its output computes the Authorization: Basic … header value directly, using the browser's own btoa, not a hand-written Base64 routine.

Known limitations

• -F / --formMultipart bodies are detected and the fields are listed, but no code is generated for them — see above.
• PowerShell / cmd quotingOnly bash/POSIX-style single and double quotes and backslash line-continuation are parsed. A command copied from Windows PowerShell's "Copy as cURL" uses different quoting and will not parse correctly here.
• $'...' ANSI-C quotingNot recognised — rare in copy-pasted commands, but if present the tokeniser will misread it.
• -b file / -c file / -K fileCookie-jar and config files are not read — only inline name=value cookies passed to -b are used; a bare filename is flagged and ignored.
• Multiple URLs in one commandcurl would fetch every one; this tool builds a single request and uses only the first.
• Unrecognised flagsIgnored, with a note. If an unrecognised flag normally takes a value, that value is not consumed and may be mis-read as the URL — check the parsed URL matches what you expect.
• -k / --insecureFlagged in Notes when present. None of the generated snippets disable certificate verification — that is a deliberate choice, not an oversight, since turning it off is a real security risk worth adding by hand, on purpose, if it's genuinely needed.
• -L / --location, --compressedNo note is shown for these — fetch, axios, requests and HttpClient all follow redirects and handle compression by default already, so there is nothing to translate.