curl converter for nine languages

Three things do it, and two of them are in your own command. -G moves everything you passed with -d into the query string and leaves the method as GET, which is the whole point of the flag. -X GET with -d keeps the body but many servers and client libraries drop the body of a GET, so the request arrives looking empty. The third is -L: when curl follows a 301, 302 or 303 it rewrites the method to GET and discards the body, exactly as browsers do, unless you add --post301, --post302 or --post303. The summary panel flags all three cases.

Because -d without a Content-Type header makes curl label the body application/x-www-form-urlencoded, whatever it actually contains. Send a JSON object that way and a strict API rejects the media type before it ever looks at the payload. Either add -H 'Content-Type: application/json' or use --json, which sets both Content-Type and Accept in one flag from curl 7.82 onwards. This converter reproduces curl's behaviour rather than quietly correcting it, and it puts a warning under the summary when a JSON-looking body has no Content-Type.

Yes, in the sense that matters: the command never leaves your browser. Parsing and code generation are JavaScript running in this tab, there is no request to any API, and nothing is logged — you can disconnect from the network and the page keeps converting. The token is still a token, so the usual care applies to the snippet you paste into a chat afterwards.

Anything that describes the transport rather than the HTTP request: -x proxies, --cert and --key client certificates, --resolve DNS overrides, --unix-socket, -T file uploads and --aws-sigv4 signing. They are recognised and listed under the summary as not carried over, rather than silently dropped, because a snippet that quietly omits a client certificate is worse than one that says it did. Flags that only affect curl's own console output — -s, -v, -i, -o, -w — are dropped without comment, since they change nothing about the request.

Because data= sends the exact bytes curl would have sent. Passing json= hands the object to Python's serialiser, which re-orders nothing but does change whitespace, escaping and float formatting, and it sets Content-Type itself — so the request on the wire is no longer the request you tested. Where an API signs the request body, or where a webhook receiver compares an HMAC over the raw bytes, that difference is the entire bug. The same reasoning is why the Go output uses strings.NewReader over a struct literal.

That is the case it was built for. DevTools writes bash-style output with single-quoted values, escapes an embedded apostrophe as '\'' and switches to $'…' ANSI-C quoting when the body contains a newline or a control character — all three are handled, along with backslash line continuations and the caret continuations of the Windows cmd variant. A trailing shell pipeline such as | jq . is dropped, with a note, because it is shell rather than part of the request.

No, and no browser API can. Certificate validation is enforced by the network stack, not by JavaScript, so there is no fetch option to skip it — in Node you would pass an undici Agent with connect.rejectUnauthorized set to false, which is a server-side decision. Seven of the remaining eight targets express it directly: verify=False in requests, InsecureSkipVerify in Go, CURLOPT_SSL_VERIFYPEER in PHP, an https.Agent in axios, DangerousAcceptAnyServerCertificateValidator in C#, VERIFY_NONE in Ruby and -SkipCertificateCheck in PowerShell 6 or newer. Java is the eighth and needs a hand-built SSLContext, so the snippet says so instead of pretending.