HTTP Request Tester
Send an HTTP request from the page, import it from curl and export it back to curl.
Request
The request goes from your browser straight to the address you type — nothing is
relayed through this site, and no server of ours ever sees it. That also means the
browser's own rules apply: the target has to allow cross-origin reads with
Access-Control-Allow-Origin, or the reply is blocked before any page could
read it. A blocked reply shows up as a failed request with no status, which is the
browser refusing, not the API being down.
curl
Parsing and building curl happens in the page and never touches the network. Options that
have no browser equivalent — -F file uploads, -T,
--connect-timeout — are listed after an import instead of being dropped
quietly, and the generated command is written to be pasted back in.
Response
Save what you type here, on this device? Your work would go into this browser's local storage, so a refresh or a trip to another tool does not wipe it. It is never uploaded, and there is no account.
Being straight about the trade-off: anything kept there can be read by anyone who can use this browser profile, and by any script that later runs on this site. A tool page can hold a private key, a password or a signed token. Saving is convenient; it is not private.
Saved on this device.
Not saved — this page forgets your work when you leave it.
About this tool
A request builder that also speaks curl. Paste a curl command and it is parsed into method, URL, headers and body; fill the form in and you can copy the equivalent curl command back out. The request itself is sent from your browser with fetch, straight to the address you type — nothing is relayed through this site, and no server of ours sees it. That also means the browser's own rules apply, which is the one thing this page cannot work around.
Questions
- Why did a request fail with a CORS error instead of returning a response?
- Because a page cannot ignore the same-origin policy. The target has to allow cross-origin reads by answering with Access-Control-Allow-Origin, and if it does not, the browser blocks the reply before any script can read it. This is a rule of the browser, not a bug in the tool, and a static site has no server to proxy the request through — a proxy would also mean your headers, cookies and body passing through somebody else's machine. The page says this in the error rather than pretending the server is down.
- Which curl flags are supported?
- The ones that describe a request: -X, -H, -d, --data-raw, --data-binary, --data-urlencode, --json, -G, -I, -u, -b, -A, -e, -m, --url and the common clusters such as -sSL. Flags that ask for something a page cannot do — -k, -o, --http2, --cert, --limit-rate — are named in a "Left out" list rather than silently dropped, and flags that ask for something the browser already does, such as --compressed or -L, are reported as adjustments instead. The two lists are kept separate on purpose: mixing them teaches you to ignore the one that matters.
- Is the curl command I export the same as the one I pasted?
- For the parts that describe the request, yes — and where it differs, the page says so. Two examples it will tell you about: --data-binary sends no Content-Type at all in curl, while this form always sends one; and --data-urlencode encodes its value as a whole, where curl encodes only the part after the first =. Everything else, including -G moving data into the query string with the values percent-encoded, round-trips unchanged.
- Can I send cookies to another site?
- Only if the request is same-origin or the target explicitly allows credentials. Cross-origin fetch with credentials requires the server to answer with Access-Control-Allow-Credentials as well as a specific origin, and never a wildcard. The credentials dropdown lets you ask; the browser decides.