The Devs Tools

Developer's Guide to API Tester: Best Practices and Examples

August 18, 2026 · The Devs Tools Team

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that blocks a web page from making requests to a different origin (a different domain, port, or protocol) unless the target server explicitly opts in with the right response headers, such as Access-Control-Allow-Origin. This is why pasting an API URL into a browser-based testing tool sometimes "just works" and other times fails with a cryptic network error even though the exact same request succeeds from a terminal with curl. The distinction matters: curl isn't a browser, so it isn't subject to CORS at all — CORS is enforced by the browser itself, not by the server or the network. A REST client running as a web page inherits this restriction like any other page script, which means testing an endpoint that hasn't configured CORS headers (a very common situation for internal APIs, work-in-progress backends, and third-party services not designed for browser consumption) requires either a server-side proxy or a browser extension with elevated network permissions that isn't bound by the same-origin policy.

[!TIP] Need to test an endpoint right now, including one that blocks CORS? Try our free, local API Tester to send requests directly from your browser.

What a Browser-Based Request Tester Actually Sends

A REST client running in the browser supports the full range of standard HTTP verbs and request shaping:

  • Methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
  • Custom headers: authentication tokens, content-type overrides, API keys
  • Query parameters: appended and URL-encoded automatically
  • Request bodies: raw JSON or other payload formats, attached to non-GET/HEAD requests
Method:  POST
URL:     https://api.example.com/v1/users
Headers: Authorization: Bearer <token>
         Content-Type: application/json
Body:    {"name": "Ada", "role": "admin"}

Two Paths to the Same Request

  1. Standard fetch(): works directly for any endpoint that returns proper CORS headers, including most public APIs and any backend you control and configure correctly.
  2. Privileged relay: for endpoints that don't (or can't) send CORS headers — think local dev servers still being wired up, or third-party APIs never meant for direct browser calls — a companion browser extension can dispatch the request from a background service worker context, which isn't subject to the page's same-origin policy, and relay the response back.

When a plain fetch() gets blocked, the browser's console error is the tell: a CORS failure looks like a generic network error to your application code, even though the request technically reached the server and got a response — the browser simply refuses to hand that response to your page's JavaScript.

Reading a CORS Failure Correctly

When a request fails specifically due to CORS, a few signals distinguish it from a genuine network or server error: the browser's developer console typically logs an explicit CORS-related message, the request may show as completing with a valid HTTP status when inspected at the network level, yet the response body remains inaccessible to your page's script. Contrast that with a true network failure (DNS resolution failure, connection refused, timeout) where no response was ever received at all. Recognizing which situation you're in saves time — a CORS block needs a header change on the server side or a bypass mechanism on the client side, while a network failure means the endpoint itself is unreachable.

Testing Local Development Servers

Because everything runs client-side, hitting http://localhost:3000 or http://127.0.0.1:8080 works exactly like hitting a production API — there's no need to expose your local server publicly or route requests through an external service just to poke at it during development.

Conclusion

Understanding CORS as a browser-enforced, not server-enforced, restriction explains most of the confusing failures developers hit when testing APIs from the browser. A tester that offers both a standard fetch path and a CORS-bypass fallback covers the realistic range of endpoints you'll actually need to test.