/

REST API Tester

A mini Postman in your browser — send GET, POST, PUT, or DELETE requests with custom headers and a body, then inspect the live response.

Request
Response
Send a request to see the response here.

Bookmark this tool now — skip the search next time you need it.

About REST API Tester

The REST API Tester is a small Postman that lives in a browser tab. Pick a method, type a URL, add the headers you need, paste a body when the method takes one, and send: the response comes back with its status code, how long the round trip took, how many bytes came down, every response header, and a pretty-printed body. There is nothing to install and no account to create, and no proxy sits in the middle, because the request goes straight from your browser to the API. That last part is also the one real constraint, since the browser applies exactly the same CORS rules it would apply to any other page.

Key features

  • GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS
  • Unlimited custom request headers, added as simple key and value rows
  • A raw request body, JSON or any other text, on the methods that accept one
  • Status code colour-coded by class, alongside the round-trip time and response size
  • Every response header listed in a panel you can expand when you need it
  • JSON responses pretty-printed automatically, with everything else shown exactly as received
  • Press Enter in the URL field to send, so quick repeated checks stay on the keyboard
  • Requests go directly from your browser to the endpoint, with no proxy in between and nothing logged on our side

How to use it

  1. Pick the HTTP method and type the endpoint URL.
  2. Add any headers you need, such as Authorization or Content-Type.
  3. For POST, PUT, or PATCH, paste the request body into the field that appears.
  4. Press Send request, or hit Enter while the URL field is focused.
  5. Read the status, timing, and size, expand the response headers if you need them, and copy the body.

Tips & common mistakes

  • A request that fails instantly with a network error is almost always CORS. The API has to return an Access-Control-Allow-Origin header before a browser on another origin is allowed to read the response, and no page can work around that. Test those endpoints from a terminal or a server instead.
  • Set Content-Type: application/json when you send a JSON body, or many frameworks will hand your handler an empty object.
  • Cookies are not sent to other origins here, so session-cookie authentication will not work. Use a token in an Authorization header instead.
  • Browsers refuse to let a page set Host, Origin, Referer, Cookie, or User-Agent. Rows with those names are ignored no matter what you type into them.
  • Redirects are followed automatically, so the status you see is the final one. An endpoint that answers 301 shows up as the 200 it landed on.
  • Anything beyond a simple GET, custom headers and JSON bodies included, triggers a preflight OPTIONS request first. If the preflight is refused, the real request never leaves the browser.
  • Once a request works, rebuild it with the cURL Command Builder to share it, or switch to the CORS Request Tester when the headers themselves are what you are debugging.
  • A Basic Auth header is just base64 of `user:password` — encode or decode that pair with Base64 Encode / Decode.
  • Not sure what a status code in the response means? Look it up on the HTTP Status Codes reference.
  • Pasting a raw response you got elsewhere rather than one you fetched here? Clean it up with the API Response Formatter.

Related tools

Browse all 9 Web / API tools

Frequently asked questions

10

Pick an HTTP method, enter the endpoint URL, add any headers and a request body, then press Send request or hit Enter in the URL field. The status code, response time, size, headers, and pretty-printed body all appear in the response panel.

Browsers block a page from reading a cross-origin response unless the server returns an Access-Control-Allow-Origin header that permits it. A request that fails instantly with a network error almost always means the API does not allow browser calls from other origins, and no in-page tool can change that. Test those endpoints from a terminal or a server-side client.

No. The request goes directly from your browser to the URL you type, using the native fetch API. Nothing is proxied through CodersUtility, and no URL, header, or body is stored or logged here.

Yes. Choose POST, PUT, or PATCH and a body field appears. Paste your JSON in and add a Content-Type: application/json header, or many frameworks will hand the handler an empty body.

Yes, as long as it authenticates with a header. Add Authorization: Bearer plus your token, or whatever API key header the service expects. Session cookies will not work, because browsers do not send cookies to another origin from here.

Browsers forbid a page from setting Host, Origin, Referer, Cookie, User-Agent, and a handful of others, so those rows are silently dropped no matter what you enter. That restriction comes from the browser itself, not from this tool.

Usually yes, provided your local server sends permissive CORS headers. Since this page is served over HTTPS, some browsers also treat a plain HTTP localhost call as mixed content, so check the browser console if a local request fails without reaching your server.

Redirects are followed automatically, so the status shown is the one from the final response. To inspect the redirect itself, request it with curl and the flag that stops redirects from being followed.

The body field takes raw text, so JSON, XML, or a URL-encoded form body all work if you set the matching Content-Type. There is no file picker, so multipart uploads need a different client.

No. There is no history, no collections, and no account, so reloading the page clears everything. That keeps it fast for one-off checks; use a desktop client when you need a saved suite.