API Tester

Send HTTP requests to any REST API and inspect the response - works with public endpoints and your localhost dev server

100% free. This tool needs our server to do the work, so what you submit is sent there, processed and then discarded - it is never stored.

Requests are sent directly from your browser first, so localhost and 127.0.0.1 endpoints work too - it falls back to a server-side proxy only if the browser can't reach the target directly (usually a CORS-blocked public API).

arrow_upward

Build a request on the left and hit Send to see the response here.

Jump to the next useful tool without leaving your flow.

See more

About this tool

Build and send HTTP requests (GET, POST, PUT, DELETE, etc.) with custom headers, query parameters, and a request body, then inspect the full response - similar to lightweight Postman-style testing directly in your browser. Requests go out directly from your browser first, which is what makes testing your own localhost dev server possible - a server-hosted tool can never reach your machine, but your own browser can. If the browser can't complete a request directly (usually a public API blocking cross-origin requests), it automatically falls back to a server-side proxy so the request still goes through.

Workflow

Clean up and validate API data

  1. 1Format the JSONMake it readable and catch syntax errors.Open
  2. 2Convert if neededMove between JSON, XML, YAML or CSV.Open
  3. 3Compare versionsSee exactly what changed.Open
  4. 4Test the requestSend it and inspect the response.You are here

How to use this tool

  1. Choose HTTP method and URLPick GET/POST/PUT/DELETE and enter the exact endpoint you want to test.
  2. Add query params and headersSet required headers like Authorization and Content-Type plus any query string values.
  3. Provide body if neededFor POST/PUT/PATCH requests, paste JSON or other payload format expected by the API.
  4. Send and inspect responseReview status code, headers, and response body to validate behavior and debug quickly.

How to test a REST API

Choose the method (GET to read, POST to create, PUT or PATCH to update, DELETE to remove), enter the URL, add headers such as Authorization and Content-Type, and a JSON body if the endpoint needs one. Send it and inspect the status code, the response headers and the body.

The status code tells you what happened: 200 OK, 201 created, 400 a bad request, 401 not authenticated, 403 not allowed, 404 not found, 429 rate-limited and 500 a server error.

Key features

  • Fast API debugging without installing external desktop clients.
  • Supports common request methods, headers, params, and payload testing.
  • Shows full response details for troubleshooting backend behavior.
  • Great for quick endpoint checks during frontend and backend development.

Common uses

  • Testing REST endpoints during feature development.
  • Validating auth headers and token-based access flows.
  • Checking API error responses and edge-case behavior.
  • Verifying staging APIs before release or QA handoff.

Tips for better results

  • Save sample payloads for repeat endpoint tests to speed up debugging.
  • Start with a simple GET to verify connectivity before complex body requests.
  • Match Content-Type exactly to your backend parser expectations.
  • Use realistic test data to reproduce production-like failures safely.

Mistakes to avoid

  • Forgetting auth headers and assuming the endpoint itself is broken.
  • Sending JSON with wrong Content-Type and misreading parse errors.
  • Ignoring response headers when debugging caching or CORS behavior.
  • Testing only success paths without checking error handling responses.

Frequently asked questions

You can add custom headers (including Authorization headers for tokens/API keys) to your request, so most authenticated APIs can be tested as long as you have valid credentials to include.

Requests are sent directly from your browser first, and some public APIs that don't allow cross-origin requests (no permissive CORS headers) will block that direct attempt - this tool then automatically retries the same request through a server-side proxy, so most public APIs still work even when the direct browser request is blocked.

Yes - because the request is sent directly from your own browser rather than from a remote server, it can reach http://localhost or 127.0.0.1 just like any other page open in your browser can. It still needs your local server to allow the request (CORS), which most dev frameworks permit by default in development.

Typically the response status code, headers, and body - letting you fully inspect what an endpoint actually returned, not just whether it succeeded.

Choose POST, PUT or PATCH, set the header Content-Type: application/json and put valid JSON in the body. Many APIs return 400 or 415 errors when the header is missing even if the JSON itself is fine.

200-299 means success (201 created, 204 no content); 401 means missing or bad credentials and 403 means you are known but not allowed; 404 is a wrong path; 429 is rate limiting; 500-599 are server errors.

Send it in the header the API documents, usually Authorization: Bearer <token> or a header such as X-API-Key, not in the URL, where it ends up in logs and history. Use a test key while experimenting.

Related guides