Paste the cURL. Get runnable code.
Turn a cURL command into fetch, axios, requests, httpx, Go, PHP or Rust — with the request parsed first so you can see exactly what was understood. Nothing leaves your browser.
cURL command
—Multiline commands with a trailing backslash work as-is. The output updates as you type.
Parsed request
—Warnings
0Generated code
Flags this converter understands
-X --request · -H --header · -d --data --data-raw --data-binary --data-ascii · --data-urlencode · --json · -F --form · -u --user · -b --cookie · -A --user-agent · -e --referer · -L --location · -k --insecure · --compressed · -o --output · --url · -I --head · -G --get
Anything else is reported in the Warnings panel, never silently dropped.
What this converter actually does
A cURL command is a shell command, not a data format. Before any code can be generated it has to be split into arguments the way your shell would: single quotes preserve everything literally, double quotes still honour \ escapes, and a backslash at the end of a line means the command continues on the next line. The same request copied from Chrome DevTools, from a README or from Copy as cURL in Firefox arrives with three different quoting styles, so the tokenizer here handles all of them — including the Windows ^ continuation that shows up when a PowerShell line is pasted from a blog post.
Nothing is executed and nothing is fetched. The command is tokenized, the flags are mapped onto a small request model, and that model is printed eight times in eight dialects.
Flags that decide the request
-d and its aliases (--data, --data-raw, --data-binary, --data-ascii) imply POST unless -X says otherwise — that implicit switch is the single most common reason a converted request hits the wrong method. --data-urlencode is different again: cURL percent-encodes the value for you, and so does this converter, so the generated code sends exactly the bytes cURL would have sent.
--json is shorthand for -d plus Content-Type: application/json and Accept: application/json; a Content-Type you set yourself always wins. -F switches the request to multipart/form-data, where a value starting with @ is a file attachment, < reads a file as a plain field value, and a trailing ;type=… overrides the MIME type. When the body is valid JSON it is re-indented before it is embedded, which is why a one-line -d turns into a readable object literal.
Reading the generated code critically
Every snippet is a starting point, not a finished client. They do not retry, they do not paginate, they do not validate the response schema, and they only set a timeout where the language makes that a single obvious argument. The plumbing is the boring part; the interesting part is what you do with the response.
Browsers are stricter than every other runtime here. fetch silently drops Cookie, User-Agent, Referer and Host, because those are forbidden header names by specification. A copied cURL command that carries a session cookie will look like it works in the browser and then authenticate as nobody — use the Node, Python, Go, PHP or Rust snippet when credentials matter.
Multipart is the other place where generated code diverges. In the browser the boundary must be chosen by the runtime, so the snippet deliberately does not set Content-Type and lets FormData fill it in. In Node and Python the equivalent is a library that streams the file instead of loading it into memory; for anything large, replace the file handle with a stream.
Frequently Asked Questions
Does a cURL command without -X always mean GET?
No. Any data flag — -d, --data-raw, --json, -F — switches the request to POST unless -X overrides it, exactly like curl. The badge at the top of the Parsed request panel always shows the method that was inferred, so it is worth a one-second glance before you copy anything.
Why is my Cookie or User-Agent header missing from the fetch snippet?
Browsers classify Cookie, User-Agent, Referer and Host as forbidden header names and silently discard them in fetch and XMLHttpRequest. The converter keeps them in the parsed view and in the server-side snippets, and flags the limitation in the Warnings panel instead of pretending the browser will honour them.
Is my command sent anywhere?
No. Tokenizing, flag parsing and all eight generators are plain JavaScript in this page. Nothing is uploaded, nothing is logged, and the generated code is never executed — the tool has no network access at all.
What happens to flags the converter does not know?
They appear in the Warnings panel with a short reason, and recognised-but-irrelevant flags such as -s or -v are listed separately. Silently dropping an unknown flag is how a converted request ends up subtly different from the one that worked in your terminal.
Should I commit the generated code as-is?
Use it to get the request shape right, then move the URL, token and payload into configuration. Hard-coded bearer tokens are the most common way a working snippet becomes an incident.
Related tools
WCAG contrast checker · Favicon generator · All MousyTools
Hecho por MousyDev
Creo herramientas web que respetan tu privacidad: tus datos se procesan en tu propio navegador y nunca pasan por mis servidores.