Testing APIs from the browser: what works, what CORS blocks, and why
A browser can issue any HTTP request you want. What it cannot always do is *show you the response*. That single sentence explains almost every confusing failure people hit with an in-browser API client.
What actually happens when you press Send
The HTTP Request Builder calls the native `fetch` API with your method, URL, headers and body. The request leaves your tab and goes straight to the target server — there is no proxy in between, which is why your Authorization header is never seen or logged by us. When the response comes back, the tool reports the status line, round-trip time, byte size, the readable response headers, and a pretty-printed body.
Why some responses are blocked
Cross-origin requests are governed by CORS. Unless the server replies with an `Access-Control-Allow-Origin` header that matches the calling page, the browser refuses to hand the response to JavaScript. Note the ordering: the server usually *received and processed* the request; the browser simply discards the reply. That is also why a blocked POST can still create a record.
Non-simple requests (custom headers, `PUT`, `DELETE`, JSON content types) trigger a preflight `OPTIONS` request first. If the server does not answer it with the right `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers`, the real request never fires at all.
Reading only three response headers
Even on a successful cross-origin call, JavaScript can read only the CORS-safelisted headers (`Cache-Control`, `Content-Language`, `Content-Type`, `Expires`, `Last-Modified`, `Pragma`) unless the server opts in with `Access-Control-Expose-Headers`. Missing `X-Request-Id` in the panel is a server configuration detail, not a bug in the client.
Practical ways around it
- Test against your own API and add the correct CORS headers — the CORS Config Generator writes the block for nginx, Express or Cloudflare.
- Call a same-origin endpoint: no CORS rules apply.
- Copy the generated curl, Python or HTTPie snippet and run it from a terminal, where CORS does not exist.
Why still test in the browser
Because it is the environment your frontend actually runs in. If a request works in curl but not here, you have found a real CORS or cookie problem your users would hit in production — earlier and for free.