curl to Python Converter: Turn curl Commands into requests Code
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.
Try an example: · · ·
# 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.
| curl | Python requests |
|---|---|
| the URL | first positional argument, e.g. requests.get(url) |
-X / --request | the method: requests.post(...), or requests.request("PURGE", ...) for unusual verbs |
-H / --header | an entry in the headers={...} dict |
?key=value in the URL | moved into params={...} so requests builds the query string |
-d / --data with JSON | json={...}, which also sets the Content-Type for you |
-d / --data with key=value | data={...}, sent form-encoded |
-u / --user | auth=(username, password) |
-b / --cookie | cookies={...} |
-F / --form | files={...} for file uploads, or data={...} |
--compressed | nothing 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, and basic auth. It does not yet generate multipart file uploads (-F) or translate raw cookie strings, and when it sees those it tells you rather than emitting code that looks right but is not. If you paste something it cannot fully convert, treat the output as a starting point and fill in the last piece by hand using the table above.