Sometimes one example isn't enough.

Because example.com can’t take a real request. AnotherExample gives developers a stable, controlled second origin for testing what browsers actually do with CORS.

Yes, it’s a real domain. No, it’s not a typo. That’s the point: use anotherexample.com and cors.anotherexample.com to test CORS, credentials, cookies, redirects, and preflights against a real HTTPS origin.

Choose a tool

Debug a real CORS problem

Compare your failing request with AnotherExample’s controlled second origin.

Explore CORS scenarios

Reproduce common successes and failures in the Playground.

Explain a browser error

Paste a Console message and get a local explanation of what it likely means.

Try the endpoints

Run a real cross-origin request from anotherexample.com to cors.anotherexample.com and inspect what your browser allows this page to read.

Ready.

Endpoints

ANY /api/echo

Returns method, headers, query parameters, body, IP, and timestamp.

ANY /api/cors/open

Permissive CORS with Access-Control-Allow-Origin: * for non-credentialed testing. The wildcard does not enable credentialed requests or expose non-safelisted response headers by itself.

ANY /api/cors/credentials

Reflects the request Origin and sends Access-Control-Allow-Credentials: true for credentialed CORS testing. This is a test endpoint; production APIs should allowlist trusted origins rather than reflect arbitrary origins.

ANY /api/status/:code

Return an intentional HTTP status from 200–599.

ANY /api/delay/:ms

Delay a response by up to 10,000 milliseconds.

GET /api/redirect

Test 301/302/303/307/308 redirects to safe predefined targets. Redirected preflights fail; simple cross-origin redirects are evaluated against the redirect target.

GET /api/cookie/set

Set a test cookie with Lax, Strict, or None SameSite behavior.

GET /api/cookie/check

See whether the browser sent a Cookie header back.

GET /api/health

Simple service health check.

CORS request types

Browsers can send some cross-origin requests directly, such as GET/HEAD and some POST requests that use only CORS-safelisted headers and content types. Other requests—such as PUT/DELETE, application/json posts, or requests with Authorization or custom headers—normally trigger an OPTIONS preflight first.

Quick examples

fetch('https://cors.anotherexample.com/api/cors/open')
  .then(r => r.json())
  .then(console.log);

curl https://anotherexample.com/api/status/418

curl https://anotherexample.com/api/delay/1000

curl -i 'https://anotherexample.com/api/redirect?target=example&status=302'

Cookie testing

/api/cookie/set?sameSite=Lax
/api/cookie/set?sameSite=Strict
/api/cookie/set?sameSite=None
/api/cookie/check
/api/cookie/clear

Use test data only.

Request-inspection endpoints may reflect headers and bodies. Never send production passwords, API keys, session tokens, personal data, or other secrets.