How to Test a REST API Online Without Postman
Learn how to send API requests, inspect responses, set headers, use authentication tokens, and debug REST endpoints directly in your browser — no desktop install required.
Try the free online tool mentioned in this guide:API Client
Why test APIs directly in the browser
Desktop API clients like Postman and Insomnia are powerful for team collaboration, collection management, and test automation. But for quick one-off requests — checking a public endpoint, debugging an auth header, or verifying a payload format — launching a desktop app adds friction.
A browser-based API client lets you send requests immediately without installing anything, switching applications, or maintaining a collection. It is particularly useful when you are already debugging in the browser DevTools or working from a machine where you cannot install software.
Anatomy of a REST API request
Every HTTP request has four key parts:
Method — The verb: GET (fetch), POST (create), PUT (replace), PATCH (update), DELETE (remove).
URL — The endpoint, e.g., https://api.example.com/users/42. May include query parameters: ?page=1&limit=20.
Headers — Metadata about the request. Common headers include Authorization, Content-Type, Accept, and custom API headers like X-API-Key.
Body — The request payload for POST/PUT/PATCH. Usually JSON. Must match the Content-Type header (typically application/json).
// Example: POST request structure
POST https://api.example.com/users
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json
{
"name": "Alice",
"email": "alice@example.com",
"role": "admin"
}Authentication types in API testing
Bearer token (JWT): Add Authorization: Bearer as a header. Paste the token from your login response. Use a JWT decoder to inspect the claims and check the expiry before testing.
API key: Usually sent as a header (X-API-Key: abc123) or a query parameter (?api_key=abc123), depending on the API's convention.
Basic Auth: Base64-encoded username:password in the Authorization header: Authorization: Basic dXNlcjpwYXNz.
OAuth 2.0: Obtain an access token via the token endpoint first, then use it as a Bearer token in subsequent requests.
// Bearer token
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
// API key in header
X-API-Key: sk_live_abc123xyz
// Basic Auth (base64 of "user:pass")
Authorization: Basic dXNlcjpwYXNz
// Query parameter
GET https://api.example.com/data?api_key=abc123Reading and debugging API responses
A response has three parts:
Status code — The three-digit HTTP status (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error). Always check this first — a 200 with an error in the body is an API antipattern.
Response headers — Metadata from the server: Content-Type, X-RateLimit-Remaining, Retry-After, caching headers, and correlation IDs for log tracing.
Response body — The payload, usually JSON. If it is minified, paste it into a JSON formatter to make it readable before inspecting field values.
Common API testing mistakes
Forgetting Content-Type — POST/PUT requests with a JSON body must include Content-Type: application/json. Without it, many servers reject or misparse the body.
Sending expired tokens — JWT access tokens expire (typically 15 minutes to 1 hour). Decode the token and check the exp claim before a test run.
Trailing slashes — Some APIs treat /users and /users/ differently. Check the API documentation.
Case-sensitive headers — HTTP/2 requires lowercase headers. Some API gateways normalize these; others do not. Use lowercase when in doubt.
Ignoring CORS errors — CORS is a browser security restriction, not a server-side API error. If you get a CORS error in the browser, the request may succeed from a server-side client (curl, Node). Check whether the API allows browser origins.
Testing with curl vs a browser API client
curl is ideal for scripting, CI pipelines, and reproducing requests in documentation. A browser API client is faster for interactive exploration, header autocompletion, and working alongside other browser tools.
MyDevTools API Client runs entirely in the browser, supports GET/POST/PUT/PATCH/DELETE, custom headers, authentication, JSON body editing, and shows the formatted response and status side by side.
# Equivalent curl command for the browser request
curl -X POST https://api.example.com/users \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"name":"Alice","email":"alice@example.com"}'Frequently asked questions
What is the difference between REST and GraphQL API testing?
REST uses multiple endpoints with specific HTTP methods. GraphQL uses a single endpoint (usually POST) with a query or mutation in the body. For GraphQL, use the GraphQL Formatter to write and validate queries, then send them via an API client.
Can I test APIs that require OAuth 2.0 in a browser API client?
Yes, if you manually obtain the access token first (via the token endpoint or a browser-based OAuth flow) and paste it into the Authorization header.
Why does my API request work in curl but fail in the browser?
Most likely a CORS issue. The browser blocks cross-origin requests if the server does not include the appropriate Access-Control-Allow-Origin header. This is a browser security policy, not an API error.
How do I test a paginated API?
Send the first request and check the response for pagination metadata (next page URL, cursor, or total pages). Then modify the query parameter (page=2, cursor=abc) and repeat. An API client makes this faster than curl for interactive exploration.