Debug CORS preflight requests

Open this example in CORS Debugger

Open the tool, then paste the sample input below. Everything runs locally in your browser.

The problem

CORS failures often look like generic browser errors. The useful detail is in the request method, custom headers, credentials mode, and the server CORS response headers.

Sample input

Preflight inputs

Origin: https://app.example.com
Method: PUT
Request headers: Authorization, Content-Type
Response Access-Control-Allow-Origin: https://app.example.com

Expected output

CORS diagnosis

Check Access-Control-Allow-Methods includes PUT
Check Access-Control-Allow-Headers includes Authorization and Content-Type

How to do it

Enter the requesting origin.
Choose the HTTP method.
Add custom request headers.
Paste the server CORS response headers.
Review which browser check fails.

Common mistakes

Adding CORS headers to the frontend instead of the API response.
Forgetting OPTIONS handling on the server.
Using wildcard origins with credentialed requests.
Missing Access-Control-Allow-Headers for Authorization.

Related tools

FAQ

Why does cURL work but the browser fails?

cURL does not enforce CORS. Browsers enforce CORS using response headers from the API.

What triggers a preflight request?

Non-simple methods, custom headers, and some content types cause the browser to send an OPTIONS preflight.

Does this call my API?

No. It simulates the browser checks from the values you enter.

Is my data uploaded anywhere?

No. This workflow runs locally in your browser unless you explicitly copy or share the result yourself.

This guide uses browser-local tooling. Avoid pasting production secrets unless you understand what the tool displays and shares.

Explore related tools

Continue with adjacent browser-based tools for the same workflow.

View security debugging tools →

Debug a CORS preflight failure: quick answer

Use this when the browser blocks a request before your application code receives the response. Paste or load the artifact into the linked tool, run the local check, then copy only the safe result or summary into your PR, ticket, or test notes.

What to verify

Compare Origin, Access-Control-Allow-Origin, allowed methods, allowed headers, credentials, and the OPTIONS status code. If a result will be shared outside your team, run a privacy or secret scan first and replace real values with safe examples.

Recommended next steps

Open CORS Simulator for the main task.
Use HTTP Headers Parser when you need a second validation pass.
Return to Use Cases to find related workflows for the same artifact.

Practical example and expected result

Simulate browser CORS and preflight checks locally to understand which response header is blocking a frontend API request. In practice, this is most useful when you need a quick, repeatable check on a developer artifact before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is Origin: https://app.example.com Method: PUT Request headers: Authorization, Content-Type Response Access-Control-Allow-Origin: https://app.e.... The expected result should resemble Check Access-Control-Allow-Methods includes PUT Check Access-Control-Allow-Headers includes Authorization and Content-Type, with the same important values preserved.

Troubleshooting checklist

Confirm you copied the complete developer artifact and not only a partial line or truncated preview.
Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps

Open this example in CORS Debugger → for a related validation or follow-up step.
HTTP Headers Parser for a related validation or follow-up step.
HTTP Security Headers Analyzer for a related validation or follow-up step.
Use Magic Box when you are not sure which tool should handle the next artifact.

Review checklist before sharing the result

For Debug CORS preflight requests, the safest workflow is to test with a small sample, confirm the output shape, then repeat with the real artifact only when needed. Keep the original input open until you verify that no value was dropped, decoded twice, sorted unexpectedly, or changed from text into a different type.

Before copying the result into a pull request, issue, chat thread, or support ticket, scan for private values. Replace real IDs, bearer tokens, session cookies, email addresses, internal hostnames, and customer data with placeholders. If another tool is listed above, use it as the second pass rather than manually editing complex output.

Keep one line of context explaining why the transformation was needed.
Preserve enough sample structure for a reviewer to reproduce the result locally.
Note any assumptions about encoding, timezone, delimiter, schema version, or runtime environment.