cURL to Code Converter
API docs hand you a curl command, but your service needs Python, JavaScript, Go, PHP, Ruby, or PowerShell instead of a shell string. Engineers copy curl from Stripe, Linear, or OpenAI docs into a backend service and want the headers, JSON body, and auth translated without retyping. QA automation authors turn curl recipes from Postman exports into test fixtures. Docs writers generate parallel snippets for a multi-language guide in one pass. The parser here reads the command the way a shell does (single and double quotes, backslash line continuations, short-flag clusters like -sS and -L), then emits code for the language you pick. Everything runs in this tab, so tokens and passwords in the command never leave your machine.
—
Generated code
—
How the Tool Converts cURL to Code
The input goes through a shell-style tokenizer before any flag is read. Single quotes pass through literally, matching the way the shell hands curl its arguments. Double quotes honor the standard escaped characters, and a backslash at the end of a line continues the command onto the next line, which is how curl examples in documentation are usually wrapped. A hash sign at the start of a line is treated as a comment and skipped. The result is a clean token list, so a JSON body such as '{"sku":"AST-01","qty":3}' stays one token instead of splitting at every space, and the surrounding quotes are stripped exactly once.
After tokenizing, the flag reader walks short clusters and long options with the same rules. A cluster like -sS is split letter by letter: -s and -S are display options that produce a note instead of code, while -L flips follow-redirects and -k disables TLS verification. Value-taking flags (-X, -H, -d, -u, -F, -o and their long forms) consume the next token or the inline remainder of the cluster. Headers, data parts, and form fields are collected separately; the method defaults to POST when a body or form is present and GET otherwise. Content-Type is filled in only when the command does not set one: a body starting with { or [ gets application/json, a flat key=value body gets application/x-www-form-urlencoded, and --json also adds an Accept header. Each language emitter then renders the same parsed request with that ecosystem's own conventions, from requests.request in Python to Invoke-RestMethod in PowerShell.
What the parser understands
-X sets the method, -H adds a header, -d and --data-raw build a body, -F builds multipart fields, -u sets basic auth, -L follows redirects, -k skips TLS checks, -I forces a HEAD request, -G moves the data flags into the query string, and --json sets both a JSON body and the Accept header. Long forms (--header, --data-binary, --user, --referer, --cookie, --max-time, --url) are equivalent to their short versions. Duplicate headers merge the way curl sends them: cookies join with a semicolon, other repeats join with a comma, and the last Content-Type wins.
Where it stops and tells you
Some flags control the shell process rather than the HTTP request. -o saves the body to a file, -w prints a format string after the transfer, -K reads more flags from a config file. Those have no place in a requests or fetch snippet, so the tool records them as notes instead of inventing code. The same rule applies to values that come from files (-H @headers.txt, -d @body.json): the browser cannot read your disk, so the line is flagged and the rest of the request stays intact.
Before and after: split() versus a real tokenizer
const parts = cmd.split(' ');
// cmd: curl -X POST https://api.example.com/v1/users -d '{"name": "Ada", "admin": true}'
// parts[5] -> '{"name":'
// parts[6] -> '"Ada",'
// parts[7] -> '"admin":'
// parts[8] -> true}'
// single quotes left in, body broken at every spacetokens = tokenizeCurl(cmd)
// ['curl', '-X', 'POST', 'https://api.example.com/v1/users',
// '-d', '{"name": "Ada", "admin": true}']
// body arrives as one token, quotes strippedUse Cases
| Who | What they paste | What they get |
|---|---|---|
| Backend engineer wiring a third-party API | curl copied from Stripe, Linear, or OpenAI documentation | Python requests call with headers, JSON body, and auth in place |
| QA automation author building HTTP fixtures | curl recipe exported from Postman or a provider guide | fetch or requests snippet ready for the test suite |
| Docs writer maintaining a multi-language guide | one verified curl example per endpoint | six parallel snippets: Python, JavaScript, Go, PHP, Ruby, PowerShell |
Common Mistakes
- Splitting the command on spaces by hand. JSON bodies with spaces, quoted header values, and backslash continuations all break under split(); a shell-style tokenizer is the only approach that survives real documentation examples.
- Assuming a -d body is JSON. curl sends -d as application/x-www-form-urlencoded unless you pass a Content-Type header or use --json. The tool guesses JSON when the body starts with { or [, which covers most docs examples but not a body that begins with a bare string.
- Expecting -o and -w to carry over. Saving the response to a file and printing a write-out format are shell behaviors; the generated code prints status and body to stdout instead, with the original intent kept in the notes.
- Pasting commands that read values from files. -H @headers.txt and -d @body.json cannot be opened from a browser tab, so those lines are flagged. A -F field=@path keeps the filename in the code, but you must supply the actual file before the request runs.
- Leaving -k or --insecure in a command aimed at a production host. Python gets verify=False, Ruby gets VERIFY_NONE, PHP gets CURLOPT_SSL_VERIFYPEER set to false, and fetch cannot disable TLS checks at all, so the tool writes a comment instead of fake support.
- Shipping credentials embedded in the snippet. -u values and Authorization bearer tokens land verbatim in the generated code; move them to environment variables or a secrets manager before the file is committed.
Best Practices
- Use --json or set Content-Type explicitly in the source command. It removes the inference guesswork and makes the generated code match what the server actually receives.
- Keep backslash continuations when you copy from docs. The tokenizer joins the lines, so the multi-line form you see in a README parses the same as a one-liner.
- Check the warnings box after every paste. Ignored display flags, file references, and unknown options are listed there, so nothing disappears without a trace.
- Switch the target language before copying. The same parsed request is re-rendered with each ecosystem's idioms: json= in requests, FormData in fetch, SetBasicAuth in Go, CURLOPT_USERPWD in PHP.
- Replace placeholder credentials immediately after generating. Produce the snippet first for speed, then swap -u values and bearer tokens for environment-variable lookups before the code is reviewed.
- Watch the summary line while you edit. Output regenerates on every keystroke, so the method, header count, body length, and timeout shown there always reflect the current textarea content.
Frequently Asked Questions
How does the parser handle quoting, escapes, and line continuations?
A backslash at the end of a line joins the next line, so multi-line commands copied from API documentation parse as a single command. Inside single quotes every character is literal, which matches how the shell treats curl arguments. Inside double quotes, the usual escaped characters (double quote, backslash, dollar, backtick) are unescaped, and a backslash-newline pair is dropped. An unterminated quote consumes the rest of the input instead of failing, so a half-copied command still produces a usable parse plus a note.
Which curl flags are supported, and which ones are only noted?
Short and long forms of -X/--request, -H/--header, -d/--data and its variants, -F/--form, -u/--user, -A/--user-agent, -e/--referer, -b/--cookie with an inline string, -L/--location, -k/--insecure, -I/--head, -G/--get, --compressed, --json, --max-time, and --url all translate into code. Download-side options such as cookie jar files, output files (-o), write-out formats (-w), config files (-K), and resume flags have no equivalent in a requests or fetch snippet, so they are recorded as notes or metadata. Display flags like -s, -S, -v, and -i are dropped with a note because the generated code always prints the status and body. Anything else lands in the unknown-flags list so you can see exactly what was skipped.
How do -u basic auth and Authorization headers transfer into the code?
A -u user:password becomes the auth field of the parsed request. Python prints auth=("user", "pass"), Go calls SetBasicAuth, PHP sets CURLOPT_USERPWD, Ruby uses basic_auth, and JavaScript adds an Authorization Basic header built with btoa. If the command already carries -H ’Authorization: Bearer …’, the explicit header wins and no second Authorization line is added. A -u value without a colon means curl would prompt for the password, so the tool keeps the username, leaves the password empty, and adds a note.
How do -F multipart forms differ from -d bodies in the generated code?
Flags like -F ’file=@report.pdf’ -F ’title=Q3 report’ produce multipart/form-data. Python maps the fields to a files dict, where file entries become (filename, open(...)) tuples and plain fields become (None, value). JavaScript builds a FormData object and tells you to replace the placeholder with a real File object; PHP uses CURLFile, Ruby calls set_form with the multipart content type, and PowerShell passes a -Form hashtable. A -d body stays one raw string with a urlencoded or JSON content type, and a command that mixes --form with --data keeps the form fields plus a warning, because curl itself rejects that combination.
Is my curl command uploaded to a server?
No. Tokenizing, parsing, and code generation all run in this browser tab with plain JavaScript. The textarea content is never sent over the network, never written to localStorage, and never logged. You can disconnect from the network and the tool keeps converting. Treat pasted commands with the same care you give any local file, because a curl string often contains bearer tokens and passwords that end up verbatim in the generated snippet.
How does the output differ between the six languages?
Python uses requests.request with keyword arguments (json=, data=, files=, verify=False, timeout=). JavaScript emits a fetch call with a headers object, an optional FormData body, and redirect: manual when the command did not pass -L. Go builds an http.NewRequest plus a client with Timeout and CheckRedirect. PHP stays close to curl itself with CURLOPT options, Ruby uses Net::HTTP, and PowerShell 7 gets an Invoke-RestMethod splatted hashtable with SkipCertificateCheck when -k was present. Multipart uploads need a real file handle in every language, so those snippets include a placeholder you replace before running.
What happens with flags the tool does not recognize?
They are not dropped silently. Recognized display options such as -s, -v, -i, and -w push a human-readable line into the notes list, and truly unknown flags are collected separately. Both lists appear in the amber warning box under the textarea, and the unknown flags also show up in the summary line. If you add a flag and the warnings box stays empty, the tool translated it; if a flag you expected to matter is missing from the code, read the notes first.