cURL to Code

A curl command is the lingua franca of API documentation and bug reports, but sooner or later it has to become real code. Translating it by hand means knowing which flags matter, which are terminal noise, and where fetch or requests quietly behave differently than curl. This page explains what the converter does with your command and where the traps sit.

From curl command to running code

The converter reads your input in two stages, the same way your shell and curl would. First a shell tokenizer splits the command into arguments: single and double quotes, backslash escapes, $'…' ANSI quoting, and the backslash-newline continuations that make pasted multi-line commands work. The Windows variants are covered too, so a Copy as cURL (cmd) command with caret escapes parses without manual cleanup.

Then the arguments go through curl's own option grammar: bundled short flags like -sSL, values attached directly as in -XPOST, and the --option=value spelling. Out of that comes one request model, and all five targets render from it. Switching tabs re-renders instantly because nothing is parsed twice.

The part we consider non-negotiable: flags the converter cannot translate are named, not swallowed. An unknown --frobnicate produces a warning in the findings strip, -s and -v are listed as terminal-only flags that change nothing about the request, and a -b cookies.txt pointing at a cookie jar file tells you plainly that code cannot load one. Converters that drop what they do not understand produce requests that differ from the original in ways you find out at 2 a.m.

Everything runs in this browser tab. That matters more here than on most tool pages, because a copied curl command routinely contains a live session cookie or an Authorization header; ours never crosses the network.

What each target gets right

The goal is code a reviewer would wave through, not a string-by-string transliteration of the command line.

• fetch (browser). When the body is JSON, you get JSON.stringify over a real object literal instead of an escaped string, so the payload is editable the way you would have written it. Headers the browser refuses to let scripts set are handled instead of copied blindly: Cookie is on the forbidden header list, so the code carries a comment pointing at credentials: 'include', and a Referer header becomes the supported referrer option. -u turns into an Authorization header built with btoa.
• Node.js. The same fetch, native since Node 18, without the browser restrictions: Cookie headers pass through, -d @payload.json becomes readFile, and a multipart file part uses openAsBlob from node:fs so the upload streams instead of loading into memory.
• Python. requests has idiomatic parameters for almost every curl flag, and the converter uses them: json= for JSON bodies (dropping the now-redundant Content-Type header), data= as a dict for form bodies, params= for -G query data, auth= as a tuple for -u, cookies= as a dict, files= with open(…, "rb") for -F. Python literals come out as Python: true becomes True, null becomes None.
• PHP. Plain curl_setopt_array with no Composer dependency, because PHP's curl extension is literally libcurl: -x maps straight to CURLOPT_PROXY, --compressed to CURLOPT_ENCODING, file parts to CURLFile.
• HTTPie. The bonus direction for people who want a shorter command line back: JSON fields become key=value and key:=raw pairs, query parameters use ==, and -u becomes -a.

Dangerous flags stay visible. -k becomes verify=False or CURLOPT_SSL_VERIFYPEER => false with a warning comment attached, and in browser fetch, where disabling TLS verification is simply impossible, the code says so instead of inventing an option that does not exist.

Copy as cURL, straight from devtools

The most common source of a curl command today is not a terminal but the browser. In Chrome: Network tab, right-click a request, Copy → Copy as cURL. Firefox has the same menu entry. What you get is a faithful replay of the request the page made, and it is the fastest way to move a misbehaving API call into code you can iterate on: paste it here, pick a target, and start editing the object literal instead of a quoted string.

Two things about the copied command are worth knowing. First, it is long. Chrome includes every header the browser sent: user-agent, accept-language, the whole family of sec-ch-* client hints and sec-fetch-* metadata. Most of them are irrelevant to reproducing the request, and pruning the generated headers object down to the two or three that matter is usually the first edit. Second, it is a credential. The Cookie header carries your session, an authorization header carries your token. The sample button above loads a realistic Chrome-style command so you can see the shape without pasting your own.

On Windows, Chrome's Copy as cURL (cmd) variant quotes with ^" carets and continues lines with ^. The tokenizer reads that dialect too, so there is no need to hunt for the bash variant hidden in the submenu.

How the common flags map

The full flag list is three hundred entries long; the curl manpage documents them all. The converter covers the ones that shape an HTTP request. Anything outside that set lands in the findings strip by name, so you always know what was left behind.

The four kinds of request body

Most conversion mistakes are body mistakes, because curl expresses four different body formats through flags that look alike.

Form-urlencoded is what a bare -d 'user=ada&plan=pro' sends, with Content-Type: application/x-www-form-urlencoded set implicitly. Several -d flags concatenate with &. The converter decodes the pairs and hands them to the mechanism each target encodes with: URLSearchParams, a data= dict, http_build_query. --data-urlencode is the variant that encodes for you, so --data-urlencode 'q=hello world' arrives as q=hello%20world; the generated code keeps the decoded value and lets the runtime re-encode it, which is the same bytes on the wire without the double-encoding trap.

JSON is form-urlencoded's flag twin and its Content-Type opposite. -d '{"a":1}' alone sends JSON bytes labelled as a form; only the -H 'Content-Type: application/json' next to it, or the --json shortcut, makes it JSON to the server. When the converter sees the JSON Content-Type and a body that parses, it upgrades the output: an object literal with JSON.stringify in JavaScript, json= in Python. If the body does not parse as JSON despite the header, that becomes a warning instead of a silent pass-through.

Multipart comes from -F and is the only format that carries files with names and MIME types. Each target builds it with its native mechanism, and in every one of them the boundary is generated at runtime, which is why the converter deliberately drops a copied Content-Type: multipart/form-data; boundary=… header and says so: replaying the old boundary with a new body is a request no server can parse.

Raw file bodies are --data-binary @dump.bin and -T file.bin. The generated code reads the same path at runtime where the runtime can (readFile in Node, open in Python, file_get_contents in PHP); browser fetch gets an honest placeholder, because a browser cannot read a local path. One byte-level detail survives translation: plain -d @file strips CR and LF from the file, --data-binary does not, and the code comments say which one you had.

If the request you are converting is a webhook replay, the webhook payload viewer is the companion tool for inspecting the body you are about to send.

Where fetch and requests differ from curl

A correct translation is not a mirror image, because the runtimes have different defaults. These are the ones that bite:

• Redirects. curl stops at the first 301 unless you pass -L; fetch and requests follow up to their limits by default. The converter notes this rather than adding a flag, but it means a curl command without -L and its translation can see different responses from the same URL.
• Timeouts. curl waits forever unless told otherwise, and so does requests, which has no default timeout at all. fetch inherits browser-level limits of around 300 seconds. When your command has --max-time, it is translated; when it does not, adding one to the requests code is our standing recommendation anyway.
• Decompression. --compressed is an opt-in for curl and a built-in for fetch and requests. Response bodies in the generated code are already decompressed text.
• Forbidden headers. Browser fetch refuses to set Cookie, Host, Referer, Origin and the Sec-* family no matter what the headers object says: the browser drops them silently. The converter is one of the few that knows the list and routes around it where a supported option exists.
• Authentication. -u in curl negotiates; the translation pins Basic, which is nothing more than base64 of user:pass in an Authorization header. If the token in your command is a JWT you want to inspect, the JWT decoder reads it without sending it anywhere.
• TLS verification. Every runtime verifies certificates by default, like curl. The difference is how loudly you can turn it off: verify=False per request in Python, process-wide only in Node's fetch, not at all in browsers. Where the command had -k, the generated code carries the risk in a comment instead of hiding it.

We converted a few hundred of these by hand before building the tool, and the habit that stuck is to read the findings strip first, then the comments in the code. The lines that did not translate cleanly are exactly the lines that made the original command interesting.

Porting a curl command