curl to Code

What it actually parses

The input is rarely a curl command somebody typed. It is what the browser’s network tab put on the clipboard: a multi-line shell expression with backslash continuations, a dozen header flags, single-quoted values containing double quotes, and a body containing both. So the parser is a real POSIX shell tokeniser rather than a split on whitespace.

Single quotes are taken literally, double quotes honour the four escapes the shell honours, a backslash outside quotes escapes the next character, and a backslash-newline is a continuation that disappears. Anything less falls over on the first apostrophe inside a JSON body, which is why so many converters mangle a genuinely pasted command.

• Method inference matching curl’s own rule - an explicit -X wins, then a body implies POST, then GET
• Headers from -H, -A, -b and -e, plus the --flag=value spelling
• Bodies from -d, --data-raw, --data-binary and --data-urlencode
• Basic credentials from -u, emitted as the target language’s own auth mechanism

Why the parsed request is shown

Between the command and the code sits a panel listing the method, the URL, every header and the body kind. It is not decoration. When generated code does not work, the cause is almost always that the command was read differently than you assumed - a quote swallowed a flag, or the method was inferred rather than taken from the -X you thought you passed.

Showing the intermediate makes that visible at a glance instead of leaving you to reverse-engineer it from the output.

Java and Kotlin are not an afterthought

Most converters lead with Python and JavaScript, and the ones that offer Java emit HttpURLConnection - an API superseded since Java 11 that reads like it. This emits java.net.http.HttpClient, and for Kotlin it emits OkHttp: what a codebase written in the last five years actually contains.

What it will not do

It does not execute the request and never will. The whole category runs in your browser, and a tool that sent your command somewhere to be run would be the one page here that broke that claim.

Transport-level flags have no request-level equivalent and are reported rather than silently dropped. --insecure, --proxy, --cacert, timeouts and retries all belong on the client you are building rather than on the request. A dropped --insecure would hand you code that fails against the very endpoint you were testing, which is worse than being told.

Generated code is a faithful translation, not a production client: no retry, no timeout, no connection reuse, and no error handling beyond a status check.