mockdock.dev

~/tools / 12 / cors-preflight-options

CORS Headers Inspector

CORS failures are diagnosed by reading headers, so learn the three shapes by heart: the permissive wildcard 204 that unblocks everything, the credentialed setup where Allow-Origin must name one exact origin (wildcards break withCredentials), and the misconfigured response missing Access-Control-Allow-Origin — the one producing that red console error you were just googling.

compose payload

— validating —

exported mock url

—

▸ open mock ↗
simulated response headers
access-control-allow-origin: *
access-control-allow-methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-headers: Content-Type, Authorization, X-Requested-With
access-control-max-age: 86400
vary: Origin

$ man cors-preflight

Everything above is encoded into the #data= fragment of the exported URL — deflated and base64url-packed by your browser. Fragments are never sent to any server, so this mock is shareable and private. Paste the URL anywhere: a teammate's browser decodes it identically.

cat ./tldr.txt

A CORS preflight simulator shows the exact Access-Control response headers a browser expects for an OPTIONS request — permissive wildcard, credentialed single-origin, and the misconfigured case missing Access-Control-Allow-Origin — so cross-origin failures can be diagnosed by comparison.

./when-to-use-this

  • A fetch fails with a CORS policy error and you need to see which header is actually missing.
  • You added credentials: "include" and the request started failing despite a wildcard origin.
  • You are configuring a new API and want a reference for which headers a preflight must return.

./frequently-asked

Why does my request fail when Access-Control-Allow-Origin is set to *?
Because you are sending credentials. When a request uses credentials: "include" or withCredentials, the browser rejects a wildcard origin outright — Access-Control-Allow-Origin must name one exact origin, and Access-Control-Allow-Credentials must be true. This is the single most common CORS misconfiguration.
What triggers a preflight request in the first place?
Anything outside the "simple request" set: methods other than GET, HEAD, or POST; custom headers such as Authorization or X-Requested-With; or a Content-Type other than form or plain text. Sending JSON with an auth header always preflights, which is why most API calls do.
Can I fix CORS from the frontend?
No. CORS is enforced by the browser but configured entirely by the server that receives the request — the response must carry the Access-Control headers. No frontend change can grant permission the server did not give; the options are fixing the server, or routing through a same-origin proxy.

grep -i related-searches

ln -s ./related-tools