curl to Python Converter: Turn curl Commands into requests Code

Support

By Simon O'Connor<br>&middot; Updated 29 June 2026<br>&middot; Interactive tool

Paste a curl command and get clean, runnable Python that uses the requests library. The converter runs entirely in your browser, so nothing you paste ever leaves the page.

This is the conversion you reach for constantly. API documentation gives you a curl example, or you right-click a request in your browser's network tab and choose "Copy as cURL", and now you want the same call in Python. The tool below does the mechanical translation: it pulls apart the flags, maps the headers and body to the right keyword arguments, and writes out idiomatic requests code. Two toggles let you add explanatory comments or upgrade the output to a production-shaped call with a session, retries, and a timeout.

Your curl command

Annotate output with comments<br>Production-ready (Session + retries + timeout)

Try an example:<br>GET with a bearer token &middot;<br>POST JSON &middot;<br>POST form data &middot;<br>Basic auth and query params

Python

# Paste a curl command above to see the Python.

How to convert curl to Python requests by hand

The tool is fast, but it helps to know what it is doing, because once you can read a curl command you can translate any of them yourself. Every curl command is a URL plus a set of flags, and almost every flag has a direct home in a requests call. The URL becomes the first argument. The method comes from -X, or defaults to GET unless there is a body, in which case it is POST. Everything else is a keyword argument.

curlPython requests

the URLfirst positional argument, e.g. requests.get(url)<br>-X / --requestthe method: requests.post(...), or requests.request("PURGE", ...) for unusual verbs<br>-H / --headeran entry in the headers={...} dict<br>?key=value in the URLmoved into params={...} so requests builds the query string<br>-d / --data with JSONjson={...}, which also sets the Content-Type for you<br>-d / --data with key=valuedata={...}, sent form-encoded<br>-u / --userauth=(username, password)<br>-b / --cookiecookies={...}<br>-F / --formfiles={...} for file uploads, or data={...}<br>--compressednothing to do, requests requests compression by default

Two of those rows are worth dwelling on, because they are where hand-written conversions usually go wrong. The first is the body. A curl -d flag carrying JSON should become the json= argument, not data=. When you pass json=, requests serialises the dict and sets the Content-Type: application/json header for you, so you should drop that header from your headers dict to avoid stating it twice. The second is the query string. It is tempting to leave ?page=2&limit=50 glued onto the URL, but lifting it into a params= dict is cleaner, handles URL-encoding correctly, and is far easier to change later.

What the production-ready toggle adds

A bare requests.get(url) is fine for a quick script, but it has two gaps that bite in real systems. It has no timeout, so a hung server can freeze your program indefinitely, and it gives up after a single failed attempt, even when the failure was a momentary blip. The production-ready toggle closes both gaps. It wraps the call in a Session, mounts an HTTPAdapter with a Retry policy that backs off between attempts, and always passes a timeout. That is the same pattern covered in depth in the guide on timeouts, retries, and backoff.

What this tool does not handle yet

The converter covers the flags you meet in day-to-day API work: methods, headers, query strings, JSON and form bodies, basic auth, inline cookies, and curl's timeout flags. Everything else, including multipart file uploads (-F), @file bodies, and any flag it does not recognise, stops the conversion with a message instead of emitting code that looks right but is not. When that happens, treat the message as your to-do and write the last piece by hand using the table above.

Next Step:

This guide covers one production pattern. The book wires the patterns together into complete projects: API clients with retries and logging, OAuth logins, databases, test suites, and deployment to AWS. Three full chapters are free to read, no account needed.

Get the free email series

A short series of practical emails on production API patterns, plus new guides as they ship. No spam, unsubscribe any time.

Skip this if you are human

Send me the series

You are on the list

Thanks. The first email is on its way, with the rest to follow over the next couple of weeks.

Want the whole thing? All 30 chapters and six portfolio projects, lifetime access for &euro;35.<br>Get Full Access &rarr;

Start building things that ship

Read three chapters free, or get lifetime access to all thirty chapters and six portfolio projects for &euro;35.

Get Lifetime Access &middot; &euro;35<br>Read Free Chapters

30-day money-back guarantee.