How it works
- Paste a curl command - from API documentation, your terminal history, or your browser's DevTools (Copy as cURL on any request in the Network tab). Multi-line commands with
\or^continuations are fine. - Check what will be sent. The command is parsed in your browser first, and a preview shows the method, URL, every header, and the body exactly as they will go out.
- Execute. The request is sent to a small proxy - a Cloudflare Worker - which calls the API from the server side and hands the response back: status, headers, and body.
- Inspect the JSON. Click Extract Keys on a JSON response to map every field in it. From there, switch the output to typed paths, JSONPath, a tree, a TypeScript type, or formatted JSON, or open the same response in any other tool from the tabs above - it comes with you.
A worked example
Click Load sample cURL above and Execute. The command fetches one user from JSONPlaceholder, a free public test API:
curl https://jsonplaceholder.typicode.com/users/1
It comes back 200 OK with 24 response headers, including content-type: application/json; charset=utf-8. Extract Keys then turns the body into 18 key paths. With the format set to Key paths with value types:
id number
name string
username string
email string
address object
address.street string
address.suite string
address.city string
address.zipcode string
address.geo object
address.geo.lat string
address.geo.lng string
phone string
website string
company object
company.name string
company.catchPhrase string
company.bs string
One line is worth a second look: address.geo.lat is a string, not a number. The coordinates arrive as "-37.3159", so any code that does arithmetic on them has to convert first. That is exactly the kind of detail that is easy to miss reading the raw response and obvious in a typed list. Switch the format to TypeScript interface and the same fact is written into the type as lat: string;, ready to paste into a client.
Which curl options work
The command is parsed in your browser, and it is parsed the way curl parses it: every behaviour in the table below was checked by sending the same command with curl 8.5 and with this page to a local echo server, and comparing what arrived. The tests are in the site's repository.
| Option | What it does here |
|---|---|
-X, --request | Sets the method: GET, POST, PUT, PATCH, DELETE, and so on |
-H, --header | Adds a header. An explicit header always wins over the shorthand options below |
-d, --data, --data-binary, --data-raw | Sends a body and makes the request a POST; repeated -d values are joined with & |
--data-urlencode | URL-encodes the value exactly as curl does (spaces become +) |
--json | Sends a JSON body with Content-Type and Accept set to application/json |
-G, --get | Moves the -d data into the query string of a GET |
-I, --head | Sends a HEAD request - useful for checking headers alone |
-u, --user | Basic authentication, sent as an Authorization: Basic header |
-A, -e, -b | Set User-Agent, Referer, and cookies (-b "name=value") |
-s, -S, -L, -k, -v, -o, -m, -w, --compressed | Accepted and ignored: they change how curl prints or saves the response, not the request |
-F, -T, -d @file, -b cookies.txt | Refused with an explanation: they read files from your disk, which a web page cannot do |
Where curl would reject a command - --header=value instead of --header value, for instance - this page rejects it too, rather than sending something your terminal would not.
What the API receives
Because the request is made by the proxy, not by your browser, the API sees a slightly different client than it would from your terminal. There are no hidden changes, but four differences are worth knowing:
- Your headers, exactly as written. Nothing from your browser is added - no cookies, no browser headers, no
Origin. Cloudflare's network adds only transport headers such asaccept-encodingandx-forwarded-proto. - A
User-Agent, if you did not set one. curl always sends one, and some APIs refuse requests without it: without one, GitHub's API answers "Request forbidden by administrative rules. Please make sure your request has a User-Agent header". So the page sendsJSONKeyper/1.0 (+https://jsonkeyper.com/execute-curl)unless your command sets its own with-Aor-H. It appears in the request preview like any other header. - A Cloudflare IP address, not yours. APIs that only accept requests from allowlisted IP addresses will refuse it.
- A shared IP address. Rate limits on unauthenticated requests are usually counted per IP, and this one is shared with other traffic. Testing GitHub's public API this way returned "API rate limit exceeded for 172.70.219.7" after only a couple of requests from this page. If an API gives you a token for higher limits, send it with
-H "Authorization: ...".
You can see all of this for yourself: execute curl https://postman-echo.com/headers and the response lists every header the target received.
Limits
The proxy is deliberately narrow, so it cannot be used to reach anything it should not. These limits are enforced by the proxy itself, and the messages below are the ones it returns:
| Limit | Detail |
|---|---|
| Public addresses only | localhost and private or reserved IP ranges are refused: "Blocked: private or reserved IP addresses are not allowed." |
http and https on ports 80 and 443 | Anything else is refused: "Blocked: non-standard ports are not allowed." |
| 5-second timeout | A slower API gets a 504; a test against an endpoint that waits 7 seconds failed at 5.07 seconds |
| 2 MB responses | Larger responses are refused with a 413 |
| Redirects are followed | You see the final response, not the 3xx |
| Text responses | Binary content - images, PDFs - is decoded as text and will look garbled |
Is it safe to paste an API key?
Anything in the command - including an Authorization header or a key in the URL - passes through the proxy on its way to the API. The proxy does not log or store requests or responses; it has no database and no storage, and each request is handled and forgotten. The privacy policy covers this in full.
That said, the safest habit with any online tool is the same: use a test key, a read-only key, or a short-lived token, and never a production secret. When a request needs a key you would not paste anywhere, run curl in your own terminal and paste the response into the JSON key extractor instead - nothing leaves your browser that way.
When to run curl yourself instead
- The API is on your machine or network -
localhost, a staging server behind a VPN, a service on your LAN. The proxy cannot reach any of them, by design. - It is slow or large - over 5 seconds or 2 MB. For large files, the large JSON guide measures what jq and Python cost.
- The API only accepts known IP addresses.
- You are scripting it.
curl ... | jqin a terminal or CI job gives you exit codes and repeatability that a web page does not.
In all of these cases the rest of the site still works: save the response, and paste it into any of the tools.
What it is good for
- Exploring an unfamiliar API - run the example from its documentation and get the full map of the response in one step, instead of reading hundreds of lines of JSON.
- Checking the documentation is right - compare the fields the docs promise with the key paths the live API actually returns.
- Generating types from a live response - execute, extract, and switch to TypeScript.
- Comparing two environments - run the same command against staging and production, and paste the two responses into JSON Diff to see exactly which fields differ, and whether any change would break a client.
- Reading response headers - content type, caching, and rate-limit headers are all shown with the body;
-Ifetches the headers alone.
Why a proxy is needed at all
A web page cannot simply call another site's API: browsers block the response unless the API opts in with CORS headers, and most do not. That is why curl works in your terminal and the same request fails from JavaScript on a web page. The proxy makes the request from a server, where CORS does not apply, and returns the result with the headers the browser needs. Why your browser blocks API calls explains CORS in full, including what a proxy like this one does and does not change.
Frequently asked questions
Can I run a curl command online without installing curl?
Yes - paste the command above and click Execute. Your browser parses it and a proxy makes the request, so there is nothing to install. The response is shown with its status and headers, and JSON responses can be mapped, typed, formatted, or compared with the other tools.
Why does my command work in the terminal but fail here?
The usual reasons, in order: the API is on localhost or a private network, which the proxy refuses; it uses a non-standard port; it only accepts allowlisted IP addresses; it rate-limits by IP and the proxy's shared address is over the limit; or it takes longer than 5 seconds. The proxy's error message, or the API's own response, says which.
Does it support POST requests with a JSON body?
Yes. Use -X POST with -d '{"key": "value"}' and a Content-Type: application/json header, or curl's --json '{"key": "value"}' shorthand, which sets both headers for you.
Is my request logged?
No. The proxy has no database and no storage; it forwards the request, returns the response, and keeps nothing. JSON you paste into the other tools never leaves your browser at all.
Other tools
- JSON Key Extractor - the same tool, starting from JSON you paste
- JSON to TypeScript - a type from a live response, with optional and nullable fields marked
- JSON Diff - compare two responses by value or by structure
- JSON Formatter - pretty-print a response without changing a value
Written and maintained by Ashish Singh · Last updated · Changelog · Found a problem with this page? Tell me.