How to Test an API Without Postman (or Insomnia, or Hoppscotch)

You do not need Postman. You do not need Insomnia, Hoppscotch, or Bruno. You do not need to install anything on your laptop, create an account, or sign in. The browser you already have open is enough to test any API, and a small handful of free browser-based tools will cover 95% of the cases desktop clients are used for.

This post walks through a practical workflow for testing an API from the browser — picking a method, sending a JSON body, inspecting headers, reading the response, debugging a failure. The tool we use throughout is the Uttir API Tester, which runs entirely in the browser, never uploads your requests, and lets you export the request as a curl command when you need to share or script it. The same workflow works with any other client-side HTTP tester.

What a browser-based API tester does (and what it does not)

A browser-based API tester is a single page that lets you compose an HTTP request and inspect the response. You give it a URL, a method, optional headers, and an optional body. It opens an HTTP connection from your browser to the target server, displays the response status, headers, and body. That is the whole job.

It does not need a backend, a database, an account, or an install. The browser already knows how to make HTTP requests; the tool is just a UI on top of fetch(). The Uttir API Tester is one such UI. Postman is a heavier version of the same idea with local storage, collections, environments, and team sync — useful for big projects, overkill for a one-off debug.

What a browser-based tool does not do: it does not store your requests on a server, does not give you a way to share a collection with a teammate, and does not run a test suite. For those features, you need a real client. For one-off requests, debugging, and learning, the browser is enough.

How to make your first request

Open the Uttir API Tester. The form has six fields: method, URL, headers (a key-value list), body, and a Send button. To test a public API:

1. Pick the method from the dropdown (GET for reading, POST for creating, PUT/PATCH for updating, DELETE for removing).
2. Paste the URL — for a public read endpoint, this is the only required field.
3. Hit Send.

For a GET, the response section appears below the form with the status code, response time, response headers, and the response body. The body is formatted as JSON if the server says it is JSON, or shown as raw text otherwise. If the response is a 4xx or 5xx, the body usually contains an error message or a JSON object describing the failure — read it carefully, that is where the bug usually is.

How to send a JSON body

For POST, PUT, and PATCH, you usually need to send a body. Pick the method, paste the URL, click into the body field, and write JSON directly. The JSON Formatter is a good companion here — paste a JSON document, see it pretty-printed, copy the formatted version into the API Tester body field.

Most APIs expect a Content-Type: application/json header when you send a JSON body. The tester usually adds this header automatically when it detects a JSON body, but check the request preview to be sure. If the server rejects your request with a 415 Unsupported Media Type or a 400 with "invalid content type", the missing header is the first thing to check.

For form-encoded bodies (the kind you submit to a login form), pick the body type as application/x-www-form-urlencoded and write the body as key=value&key2=value2. For file uploads, use multipart/form-data and the tester usually gives you a file picker.

How to read a response

The response has three parts, in this order: status line, headers, body. Read them in that order.

Status line tells you whether the request worked. 2xx means success. 3xx means the server redirected you (most clients follow redirects automatically, but if you see 3xx, the URL you sent was not the final URL). 4xx means the request was wrong on your side — bad URL, missing auth, invalid body. 5xx means the server is broken. The exact text matters: 401 is "you need to authenticate", 403 is "you authenticated but you are not allowed", 404 is "this URL does not exist", 429 is "you sent too many requests, slow down".

Headers tell you what the server thinks the response is. The most important header is Content-Type — it tells the tester whether to format the body as JSON, HTML, XML, or plain text. The Set-Cookie header tells you what cookies the server wants you to send back. The RateLimit-Remaining header (if the server sends it) tells you how many more requests you can make before getting throttled.

Body is the actual response. For a JSON API, it is usually a JSON document — paste it into the JSON Tree Viewer if it is large, or into the JSON Validator if you suspect it is malformed. For an HTML API, the body is HTML — paste it into a code formatter to read it, or open the URL in a new tab to see the rendered page.

How to send authenticated requests

Most real APIs require authentication. The two most common patterns:

Bearer token (OAuth 2.0, JWT). Add a header Authorization: Bearer YOUR_TOKEN_HERE. The token is usually long (200+ characters) and looks random. Copy it from wherever you got it (an API dashboard, a CLI login, an env var) and paste it into the header value. Do not save it in the tester if you can avoid it — anyone who gets the URL can read the token from the URL params or the form value.

API key. Add a header X-API-Key: YOUR_KEY or a query parameter ?api_key=YOUR_KEY. The exact header name and where it goes (header vs query) is API-specific — check the API docs. If the API uses query params, the key shows up in server access logs; header-based keys are safer.

For OAuth flows with refresh tokens, the tester will not handle the refresh for you. Get a fresh token, paste it in, repeat when it expires. For long-lived API keys, the tester usually lets you save the request as a preset so you do not have to re-enter the key every time.

How to debug a failing request

When the request fails, work through this checklist in order:

1. Status code. 4xx is your fault, 5xx is the server's. If you see 4xx, fix the request. If you see 5xx, try again later or contact the API provider.
2. Response body. Most APIs return a JSON error object with a message. Read it. "Invalid API key" means the key is wrong. "Rate limit exceeded" means you sent too many requests. "Resource not found" means the URL is wrong.
3. Request headers. Click "view request" or similar to see exactly what was sent. Compare what you sent to what the API docs say is required. Missing Content-Type, wrong Authorization format, missing required header — all common.
4. URL. Encode special characters. Spaces should be %20 (or + in query strings). Ampersands in query strings must be &. The URL Encoder handles this for you.
5. CORS. If the request fails before getting a response (no status code, just a network error), the API server may be blocking browser requests for security. CORS is a server-side policy; if the API does not allow your origin, you cannot call it from the browser. Use a server-side proxy or a tool like curl that does not have a CORS check.

The Uttir API Tester shows the full request and the full response side by side, so you can compare them line by line. The request preview is usually the fastest way to find a missing header or a typo in the URL.

How to export a working request as curl

Once you have a request that works, the Uttir API Tester has a "Copy as curl" button. Click it, and you get a curl command line that reproduces the same request. Paste it into a terminal to run the request from the command line, which is useful for scripting, sharing in a bug report, or running as part of a CI pipeline.

curl is also a great teaching tool: it shows you exactly what the request looks like on the wire, with no UI abstraction in the way. If you do not understand what an HTTP request is, the curl version of a request you built in a tester is the clearest way to learn.

What to use when

For a one-off debug or a learning exercise, the browser-based tester is the right tool. For repeated use, save the request as a preset (the tester usually has a "save" or "history" feature). For team use, you need a shared client with collections and environments — that is what Postman, Insomnia, and Bruno are for. For automated testing, write the request as code (in your language of choice) and run it in CI.

The Uttir API Tester covers the first two cases. When you need more, you have graduated from "I want to test this one API" to "I want to manage a collection of APIs" — and that is a different tool for a different job.

Related tools: JSON Formatter for cleaning up the response body, JSON Validator for checking that the response is well-formed, JSON Tree Viewer for navigating large responses, UUID Generator for testing APIs that take a UUID in the path or body.