HTTP Request Tester

This tool runs entirely in your browser. Cross-origin requests may be blocked by the target server's CORS policy. If a request fails, try using cURL in your terminal instead.

Body is not available for GET requests.

No response yet

Enter a URL and click Send Request to make an HTTP request.

About the HTTP Request Tester

The HTTP Request Tester sends live HTTP/HTTPS requests from your browser to any endpoint and shows the full response — status code, headers, body, latency. Build a request visually (method, URL, headers, body) or paste a curl command. Save request collections in localStorage for reusable test fixtures. The browser's fetch implementation handles all the heavy lifting (TLS, HTTP/2 multiplexing, connection pooling), so the requests behave identically to what your application will send. Some requests are blocked by CORS — the tool surfaces clear guidance when this happens.

Updated: May 8, 2026

Related Tools

cURL ConverterConvert your tested request to code in 21 languages.Try it cURL BuilderBuild a cURL command visually before testing.Try it HTTP Header CheckerAudit response headers for security and CORS misconfigurations.Try it JWT DecoderDecode JWT tokens received in API responses.Try it JSON ViewerFormat and explore JSON response bodies in tree mode.Try it

How to use the tester

  • Pick the HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) from the dropdown.
  • Enter the request URL — the tool validates the format and warns about common mistakes (missing protocol, typos in the host).
  • Add headers via the Headers tab — each row is a name/value pair. Common headers (Authorization, Content-Type, Accept) have shortcut buttons.
  • For requests with a body, pick a body type: JSON, Form Data (multipart), URL-encoded, or Raw. The tool sets the appropriate Content-Type unless you override.
  • Click Send. The response panel shows status code (color-coded), headers, body (auto-formatted as JSON if applicable), and total latency.
  • Save useful requests to a Collection — a localStorage-backed list that persists across reloads. Useful for testing the same endpoint with different bodies during development.

Common use cases

  • Smoke-testing an API after deploy — confirm the endpoint returns the expected schema before opening the application UI.
  • Reproducing a bug from a customer report — paste the curl command they sent, see the same response.
  • Inspecting third-party API behavior — Stripe, GitHub, Slack, Twilio — without writing code first.
  • Webhook payload preview — POST a test payload to your webhook receiver and inspect the response.
  • Auth flow debugging — exchange an OAuth code for a token, inspect the JWT in the response, verify the expiry.

Privacy and security

The browser's fetch implementation makes the request directly to the target server — there is no proxy or middleware on our side. Headers, request bodies, and responses pass through your browser's network stack the same way they would from your application code. We do not log, store, or analyze any request content. Saved collections in localStorage are scoped to your browser and never synced to a server.

Tips and pitfalls

  • CORS blocks many public APIs from browser fetch. The tool surfaces a clear "CORS-blocked" message when this happens. To test those endpoints, run the request from your application (server-side) or use a CORS-friendly proxy.
  • Browser-stored cookies travel with same-origin requests automatically (the tester uses the browser's default `credentials` mode). Cross-origin cookies are NOT sent — the tester does not expose a `credentials: include` toggle. To exercise an authenticated cross-origin endpoint, run the request from your own application code where you can configure the fetch options directly.
  • TLS errors (self-signed certs, expired certs, hostname mismatches) cause fetch to reject. Browsers do not allow disabling certificate verification programmatically — for self-signed dev servers, install the cert in your OS trust store or use cURL with -k.
  • Some headers are restricted by the browser (Connection, Cookie, Date, Expect, Host, Origin, Referer, etc.). The browser may silently override your value. The tool warns when you set a restricted header.
  • Response bodies are loaded fully into memory. For large responses (multi-megabyte JSON, file downloads), the browser may stutter — better to download via the tool's Save Response button rather than rendering inline.

Frequently Asked Questions

Why does my request fail with a CORS error?
CORS (Cross-Origin Resource Sharing) is a browser security policy. When you fetch from a page on origin A to an API on origin B, the browser blocks the response unless the API server explicitly allows it via Access-Control-Allow-Origin headers. The tester runs in your browser, so CORS applies. To test CORS-restricted APIs, run the request from your backend server instead.
How do I test a request that requires cookies?
Cookies for the target domain are included automatically for same-origin requests. For cross-origin requests, enable "credentials: include" in the Advanced tab AND ensure the target server sends Access-Control-Allow-Credentials: true plus a specific Access-Control-Allow-Origin (not `*`).
Can I save and reuse requests?
Yes. Click Save to add the current request to your Collection — a localStorage-backed list. Collections persist across page refreshes and are scoped to your browser (not synced to a server). For team-shared collections, export and share the JSON.
Does the tester support HTTP/2 and HTTP/3?
Yes — automatically. The browser negotiates the highest protocol version both endpoints support. Modern browsers (Chrome 87+, Firefox 88+, Safari 14+) support HTTP/2; HTTP/3 (QUIC) is enabled by default in Chrome 80+ and Firefox 88+ where the server supports it.
How do I import a curl command?
Paste the curl command into the import field; the tool parses the URL, method, headers, and body. Use the cURL Converter at /curl-converter for more advanced parsing or to convert the curl command to language-specific code.
Are my requests proxied through your servers?
No. The tester uses your browser's native fetch, which sends the request directly from your browser to the target server. We have no proxy, no middleware, no logging of request content. Open DevTools Network tab while you click Send — you will see the request originate directly from your browser.
How do I test authenticated endpoints?
For Bearer tokens: add an Authorization header with value "Bearer <token>". For Basic auth: use the Auth tab to enter username/password (the tool encodes them). For OAuth flows: complete the auth flow in another tab, copy the token, paste it into the tester. For mTLS: not supported in the browser fetch API — use the cURL Converter to generate code that runs in a server-side environment.
Can I see the request that was actually sent?
Yes. After Send, the Request panel shows the exact wire-level request the browser produced — including headers added automatically by the runtime (User-Agent, Accept-Encoding, Connection). Useful for reconciling discrepancies between what you configured and what the server received.