Skip to main content
Home Tools API Request Tester
🔧 Programming ✅ 100% Free ⚡ Instant

API Request Tester

Send GET, POST, PUT, PATCH, and DELETE requests with custom headers and a JSON body, then view the formatted response — status, headers, timing, and body. Requests are sent directly from your browser using fetch(), so they're subject to the target API's CORS policy.

Send a request to see the response here.
📚 Try a Sample API
🌐 About CORS
🔒
Browser security — browsers block JavaScript from reading responses from a different origin unless that server explicitly allows it.
Public APIs usually work — most public REST APIs (like JSONPlaceholder, GitHub API) set permissive CORS headers.
🖥️
Your own APIs — if testing your own backend, add Access-Control-Allow-Origin: * (or your domain) to enable browser testing.
🔒
100% private — requests go directly from your browser to the API. Nothing passes through our servers.

What is an API Request Tester?

An API request tester (sometimes called a "REST client") lets you send HTTP requests to an API endpoint and inspect the response — status code, headers, and body — without writing any code. It's the browser-based equivalent of tools like Postman or Insomnia, useful for quickly checking whether an endpoint works, exploring an unfamiliar API's response shape, debugging authentication issues, or testing your own backend during development.

This tool sends requests directly from your browser to the target API using the standard fetch() API — no requests pass through any intermediate server.

How to Use This Tool

  • Choose a method — GET, POST, PUT, PATCH, or DELETE.
  • Enter the endpoint URL — must be a full URL including https://.
  • Add headers — common headers like Content-Type: application/json or custom API keys.
  • Set a request body — for POST/PUT/PATCH, switch to the Body tab and write JSON or raw text.
  • Add authentication — Bearer token or Basic Auth credentials are added automatically as the correct header.
  • Send and inspect — view the status code, response time, headers, and formatted body.

Understanding CORS

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that blocks a web page from one origin (domain) from reading responses from a different origin, unless that server explicitly allows it via the Access-Control-Allow-Origin response header. This means: requests to APIs that don't set permissive CORS headers will fail when sent from a browser-based tool like this one — not because the API is broken, but because your browser is protecting you. Most public APIs (GitHub, JSONPlaceholder, many others) are configured to allow this. If you're testing your own backend and see a CORS error, add the appropriate header on your server.

Frequently Asked Questions

This generic error usually means one of: (1) the target API has a restrictive CORS policy that blocks browser requests from this domain, (2) the URL is incorrect or the server is unreachable, (3) the API requires HTTPS but you entered HTTP (mixed content is blocked), or (4) a network connectivity issue. Browser developer tools (F12 → Console/Network tab) often show more specific error details.
Requests are sent directly from your browser to the target API — your API key travels only between your browser and that API's servers, the same as it would from any application. However, as a general security practice, avoid testing with production API keys that have write/delete permissions, and never share screenshots or recordings that include visible API keys or tokens.
Yes, if the local server has CORS configured to allow requests from this page's origin, and the local server is reachable from your browser (e.g. http://localhost:3000). Some browsers block "mixed content" — requests from an HTTPS page to an HTTP localhost — depending on browser settings.
PUT is meant to replace an entire resource — the request body should contain the complete representation of the resource. PATCH is meant for partial updates — the request body contains only the fields that should change. In practice, many APIs treat them similarly, but following the convention helps API consumers understand the intent of each request.
Switch to the Auth tab, select "Bearer Token", and paste your token. This automatically adds an Authorization: Bearer <your-token> header to the request — the standard way most modern APIs authenticate requests using OAuth2 access tokens or JWTs.
415 Unsupported Media Type usually means the API expected a specific Content-Type header that wasn't sent or didn't match the body format. When sending JSON, ensure the Body tab is set to "JSON" — this automatically sets Content-Type: application/json. If the API expects form-encoded data instead, you may need to add that Content-Type header manually and format the body accordingly.
Copied!