How it works

  1. 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.
  2. 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.
  3. 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.
  4. 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.

OptionWhat it does here
-X, --requestSets the method: GET, POST, PUT, PATCH, DELETE, and so on
-H, --headerAdds a header. An explicit header always wins over the shorthand options below
-d, --data, --data-binary, --data-rawSends a body and makes the request a POST; repeated -d values are joined with &
--data-urlencodeURL-encodes the value exactly as curl does (spaces become +)
--jsonSends a JSON body with Content-Type and Accept set to application/json
-G, --getMoves the -d data into the query string of a GET
-I, --headSends a HEAD request - useful for checking headers alone
-u, --userBasic authentication, sent as an Authorization: Basic header
-A, -e, -bSet User-Agent, Referer, and cookies (-b "name=value")
-s, -S, -L, -k, -v, -o, -m, -w, --compressedAccepted and ignored: they change how curl prints or saves the response, not the request
-F, -T, -d @file, -b cookies.txtRefused 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 as accept-encoding and x-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 sends JSONKeyper/1.0 (+https://jsonkeyper.com/execute-curl) unless your command sets its own with -A or -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:

LimitDetail
Public addresses onlylocalhost and private or reserved IP ranges are refused: "Blocked: private or reserved IP addresses are not allowed."
http and https on ports 80 and 443Anything else is refused: "Blocked: non-standard ports are not allowed."
5-second timeoutA slower API gets a 504; a test against an endpoint that waits 7 seconds failed at 5.07 seconds
2 MB responsesLarger responses are refused with a 413
Redirects are followedYou see the final response, not the 3xx
Text responsesBinary 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 ... | jq in 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; -I fetches 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

Written and maintained by Ashish Singh · Last updated · Changelog · Found a problem with this page? Tell me.