API Tester & Debugger

Send HTTP requests directly from your browser. Supports all methods, custom headers, JSON/Form data, and full response inspection. Perfect for API development, debugging, and learning HTTP. No server‑side logging – 100% client side.

Raw body – remember to set appropriate Content-Type header (e.g., application/json).
? GET post 1 ? POST new post ? GitHub user ⏳ Delayed (2s) ? Echo POST
Privacy first: Requests are sent directly from your browser. We do not proxy or log your data. CORS restrictions apply – use public APIs or enable CORS on your endpoint.

Why a browser‑based API tester?

Debugging APIs should be fast and frictionless. This tool lets you craft HTTP requests, inspect responses, and understand REST/GraphQL interactions – all without leaving the browser. Whether you're a backend developer testing endpoints, a frontend engineer mocking data, or a student learning HTTP, this tester provides immediate feedback with full transparency.

HTTP request lifecycle at your fingertips

Method + URL + Headers + Body → Status + Headers + Body

Deep dive: how requests are handled

This tool uses the browser's native fetch() API. No intermediate server means your data stays private. However, the same‑origin policy (CORS) applies: if the target API does not include appropriate Access-Control-Allow-Origin headers, the browser blocks the response. For learning and testing, we recommend public CORS‑enabled APIs (like JSONPlaceholder, httpbin.org). For your own APIs, ensure CORS is configured during development.

Under the hood, we construct a Request object with your method, headers, and body. The response is read via res.text() (or you can choose format; we display plain text). Headers are iterated and shown in a readable format. The time measurement starts just before fetch and ends when the response is fully received.

HTTP methods & semantics

Method Idempotent Safe Typical use
GET ✅ ✅ Retrieve resource
HEAD ✅ ✅ GET without body (check headers)
POST ❌ ❌ Create new resource
PUT ✅ ❌ Replace resource entirely
PATCH ❌* ❌ Partial update
DELETE ✅ ❌ Remove resource
OPTIONS ✅ ✅ CORS preflight / capabilities

* PATCH can be idempotent if designed so, but not guaranteed by spec.

Status code quick reference (RFC 9110)

Code Category Examples
1xx Informational 100 Continue, 101 Switching Protocols
2xx Success 200 OK, 201 Created, 204 No Content
3xx Redirection 301 Moved Permanently, 304 Not Modified
4xx Client Error 400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests
5xx Server Error 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
Case Study: Debugging Payment API Integration

A development team was integrating Stripe payments but kept receiving 400 Bad Request with cryptic errors. Using this API tester, they constructed the exact request (POST with secret key in headers, JSON body) and saw the full error response: "amount must be at least 50 cents". The formatted response body made it clear – a missing decimal point. The team fixed the payload and the integration succeeded. The ability to quickly replay requests without Postman's overhead accelerated the debugging cycle.

Authentication & authorization patterns

Add the appropriate header manually:

  • Basic Auth: Authorization: Basic
  • Bearer Token (OAuth2, JWT): Authorization: Bearer <token>
  • API Key: often as header X-API-Key: your-key or as query parameter.

Never share real credentials; use mock tokens for testing.

Common pitfalls & misconceptions

  • CORS errors: They appear as network errors in the console. This tool shows a clear message when a CORS block occurs.
  • GET with body: The fetch API ignores the body for GET/HEAD; we disable body input automatically.
  • Content-Type mismatch: If you send JSON but omit Content-Type: application/json, the server may not parse it.
  • Redirects: fetch follows redirects by default; the final response is shown (status 200).

Beyond REST: testing GraphQL endpoints

GraphQL usually uses POST with a JSON body containing query and variables. Set method to POST, URL to your GraphQL endpoint, headers Content-Type: application/json, and body like {"query":"{ user(id:1) { name } }"}. This tester works perfectly for GraphQL introspection or queries.

Built by developers for developers – This API tester was created by the GetZenQuery engineering team to provide a lightweight, transparent alternative to heavy GUI tools. We rely on it daily for sanity‑checking endpoints. Reviewed against MDN fetch spec, OWASP secure coding practices, and real‑world API guidelines. Last updated March 2026.

Frequently Asked Questions

Browsers block requests to a different origin unless the server allows it via Access-Control-Allow-Origin. Use a public CORS‑enabled API or a local proxy. For development, you can disable CORS in browser (not recommended) or use an extension.

Currently the tool supports raw text body. To send multipart/form‑data, you would need to construct a FormData object – this is planned for a future update. For now, you can use curl for file uploads.

We use performance.now() before and after fetch. The time includes network latency, server processing, and response download. It's a close approximation of total round‑trip time.

By default, fetch does not send credentials (cookies). To include them, we would need to set credentials: 'include' – currently not implemented to keep privacy. You can manually add cookie headers if needed.

Excellent resources: MDN HTTP, HTTP Working Group, and the book "HTTP: The Definitive Guide".
References: Fetch Standard; MDN Status Codes; OWASP CORS guidelines.