# curl command explainer

> Paste a curl command and get it explained flag by flag, then translated to fetch, a raw HTTP request, HTTPie and Python. Nothing is sent and no request is run.

- Tool: https://ronutz.com/en/tools/curl-command-explainer
- Family: Web & HTTP

---

## What it does

Paste a `curl` command and the tool explains it flag by flag, then translates it into four other forms: a browser `fetch` call, a raw HTTP request, an HTTPie command, and Python `requests` code. The command is tokenized and decoded in your browser; nothing is ever sent, and no request is run.

## One parse, five views

Under the hood there is a single step: the tool parses your `curl` command into one request model, capturing the method, the URL, the headers, the body, authentication, and the other options. Everything you see is derived from that one model. Because translating a command correctly already requires understanding every flag, the flag-by-flag explanation is just that same model shown with labels, which is why the explanation and the translations always agree.

## The forms it produces

- **curl explained.** Each option is named and described, so an unfamiliar flag stops being a mystery.
- **fetch.** The browser Fetch API call, following the MDN semantics, ready to drop into JavaScript.
- **Raw HTTP.** The actual request line, headers, and body as they would go on the wire, which is the clearest way to see exactly what a request is.
- **HTTPie.** The equivalent `http` command, for those who prefer that client.
- **Python requests.** The equivalent code using the Requests library.

## Why translate rather than run

The tool deliberately never executes the request. That is a privacy and safety choice: you can decode and convert a command that carries credentials or points at an internal host without any of it leaving your browser, and without triggering whatever the request would do. It is a translator and an explainer, not a client.

## Using it

Paste a `curl` command and read the flag-by-flag explanation and the four translations. The conversion is deterministic and local, so the same command always produces the same output.

The inverse tool is the [HTTP request translator](https://ronutz.com/en/tools/http-request-translator): paste a raw request and get a runnable command back. If you arrived here looking for that, it moved to the name it describes.

## Standards and references

- [curl - man page (command options)](https://curl.se/docs/manpage.html)
- [RFC 9110 - HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110)
- [MDN - Using the Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)
- [HTTPie - Documentation](https://httpie.io/docs/cli)
- [Requests - Quickstart](https://requests.readthedocs.io/en/latest/user/quickstart/)

## Related reading

- [AJAX, XHR, and fetch: When Pages Learned to Talk Back](https://ronutz.com/en/learn/ajax-fetch-and-xhr.md): For its first decade the web had one move: click, blank screen, new page. XMLHttpRequest gave pages a second one - request data in the background, update in place - and 'AJAX' named the revolution (which promptly dropped the X for JSON). How XHR worked, what fetch fixed (promises, streams, a sane API), what stayed the same underneath (it is all still HTTP), and the boundary every background request answers to: same-origin, with CORS as the negotiated exception.
- [CORS Explained: The Border Control of the Browser](https://ronutz.com/en/learn/cors-explained.md): CORS is the most misunderstood error message in web development, because it punishes the wrong mental model. It is not a wall - the same-origin policy is the wall; CORS is the door: a header protocol by which a server volunteers 'that other origin may read my responses.' Simple requests vs preflights, what OPTIONS is doing in your network tab, why credentials tighten every rule, why '*' is not the fix, and why CORS never protected the server in the first place.
- [curl Data Flags and the Content-Type Trap](https://ronutz.com/en/learn/curl-data-flags-and-content-type.md): curl has several ways to attach a body, and they differ in encoding and default Content-Type. The big surprise is that -d defaults to form encoding, not JSON, so a JSON body can be mislabeled and rejected.
- [curl Flags That Change Security Posture](https://ronutz.com/en/learn/curl-security-flags.md): A few curl flags change how safe a request is: -k disables TLS verification, http sends everything in clear text, and credentials in the URL can leak. None make a request malicious, but each is worth reading before you run or share a command.
- [Headers, Authentication, and Cookies in curl](https://ronutz.com/en/learn/curl-headers-auth-and-cookies.md): Headers, auth, and cookies are how a request identifies and authorizes itself. -H adds headers, -u is HTTP Basic, a bearer token is just a header, and -b/-c handle cookies. All of them are sensitive.
- [How curl Infers the HTTP Method](https://ronutz.com/en/learn/curl-method-inference.md): curl does not always need -X to choose a method. Body data implies POST, -I implies HEAD, -G forces GET, and an explicit -X always wins. Knowing the rules tells you at a glance what a request will do.
- [HTML Forms and Request Encoding: How the Web Ships Your Input](https://ronutz.com/en/learn/html-forms-and-request-encoding.md): A form is a contract between a page and a server: which fields, which verb, which wire format. GET puts the answers in the URL; POST puts them in the body; and enctype picks the body's dialect - urlencoded's key=value chains, multipart's boundary-delimited parts built for files. What each choice means for logs, caches, size limits, and debugging, plus the fetch-era footnote: FormData kept the formats alive after forms stopped being the only sender.
- [HTTP Cookies: State Over a Stateless Protocol](https://ronutz.com/en/learn/http-cookies-state-over-stateless.md): HTTP forgets you after every request - by design. Cookies are the retrofit that lets it remember anyway: the server writes a note with Set-Cookie, the browser returns it with Cookie, and everything else - scope, lifetime, security - is rules about when that note travels. Domain and Path scoping, session vs persistent lifetimes, why the server never sees what the browser knows, and where the security flags article picks up.
- [HTTP Headers: The Anatomy of the Metadata](https://ronutz.com/en/learn/http-headers-anatomy.md): Everything HTTP knows about a message that isn't the message travels in headers: name-colon-value lines with case-insensitive names, folded into four working roles - request context, response context, representation metadata, and payload plumbing. The end-to-end vs hop-by-hop split that proxies live by, the Host header that made virtual hosting possible, content negotiation, conditionals, and why header order became a fingerprint.
- [HTTP Methods: The Verbs of the Web](https://ronutz.com/en/learn/http-methods-the-verbs.md): GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, TRACE, CONNECT - and now QUERY. What each method promises, why 'safe' and 'idempotent' are the two properties that actually matter (to caches, retries, proxies, and crawlers), why HTML forms only ever learned two verbs, and how to read an API's soul from the methods it accepts.
- [HTTP QUERY: the read that finally carries a body](https://ronutz.com/en/learn/http-query-method.md): RFC 10008 (June 2026) gave HTTP its first new method since 2010: QUERY is safe, idempotent, and cacheable like GET, but carries a request body like POST. What it fixes, how its caching and discovery work, why 'safe' is not 'harmless', and what every layer of infrastructure must check before QUERY traffic arrives.
- [HTTP Status Codes: The Five Families](https://ronutz.com/en/learn/http-status-codes-the-five-families.md): Three digits, and the first one does most of the work: 1xx continues, 2xx succeeds, 3xx redirects, 4xx blames the client, 5xx confesses for the server. The family logic, the codes an operator actually meets (200, 204, 301 vs 302 vs 307, 304's cache dance, 401 vs 403, 404 vs 410, 429, 500 vs 502 vs 503 vs 504), the famous curiosities, and why an unknown code's first digit is always enough to act on.
- [Reading a curl Command](https://ronutz.com/en/learn/reading-a-curl-command.md): A curl command is a shell command: the word curl, a set of options, and a URL. Reading it means seeing how the shell splits the line first (quotes, backslashes, line continuations) and then how curl reads short, long, and clustered flags.
- [Reading a raw HTTP request, and turning it back into something you can run](https://ronutz.com/en/learn/raw-http-requests-and-how-to-replay-them.md): A capture, a proxy log and an RFC example all hand you the same thing: a request line, some headers and maybe a body. Turning that back into a command you can run looks mechanical and has three traps - the URL is not in the message, some headers must not be copied, and the paste is usually a live credential.
- [The 27 Protocols curl Speaks](https://ronutz.com/en/learn/curl-protocols-beyond-http.md): curl is known as an HTTP tool, but the current tool speaks 27 URL schemes: file transfer over FTP, SFTP and SMB, mail over SMTP, POP3 and IMAP, MQTT publish-subscribe, LDAP lookups, and relics like Gopher, DICT and Telnet. Knowing the map, and which schemes start in cleartext, changes how you use it.
- [Translating curl to fetch()](https://ronutz.com/en/learn/curl-to-fetch.md): The browser fetch API and curl describe the same request differently. Method, headers, and body map across cleanly, but a couple of differences (implicit form Content-Type, cookies, and TLS verification) need care.