What exactly defines an origin?

An origin is the tuple of scheme, host, and port. Two URLs are same-origin only if all three match exactly. https://example.com and http://example.com differ by scheme; example.com and www.example.com differ by host; port 80 and 8080 differ by port.

Is the path part of the origin?

No. The path, query string, and fragment are ignored. https://example.com/a and https://example.com/b/c?x=1 are the same origin because the scheme, host, and port are identical.

What are the default ports?

http defaults to port 80 and https to port 443. A URL with no explicit port uses the default for its scheme, so https://example.com and https://example.com:443 are the same origin.

How do I allow a legitimate cross-origin request?

Use CORS: the server adds Access-Control-Allow-Origin (and related) headers to opt specific origins into reading the response. For window-to-window messaging use postMessage with a strict targetOrigin, and use CORP/COEP headers to control resource embedding.

Does the same-origin policy block sending requests?

Mostly it blocks reading cross-origin responses, not sending. A form post or simple fetch can reach another origin, but JavaScript cannot read the response unless CORS permits it. This is why CSRF protections matter even though SOP is in force.

Same-Origin Policy Checker & Explainer

The same-origin policy (SOP) is the foundation of browser security: it stops a page on one origin from reading data from another. This tool compares two URLs, tells you precisely whether they are same-origin, and explains the consequences.

How it works

An origin is the combination of three things:

Scheme (protocol) — http vs https
Host (hostname) — example.com vs www.example.com vs api.example.com
Port — explicit, or the scheme default (80 for http, 443 for https)

Two URLs are same-origin only if all three match exactly. Everything after the host and port — the path, query string, and #fragment — is irrelevant to the origin.

The tool parses each URL with the browser’s own URL parser, normalises the port (filling in 80/443 when omitted), and compares the three components individually. It then reports which component, if any, caused a cross-origin result.

What a cross-origin result means

When two contexts are cross-origin, the browser blocks the calling page from reading the other’s data. Concretely:

fetch()/XMLHttpRequest can send the request, but JavaScript cannot read the response body unless the server returns matching CORS headers.
A script cannot read the DOM, cookies (with the right flags), or localStorage of a cross-origin iframe.
Canvas pixels drawn from a cross-origin image become “tainted” and unreadable.

Note the asymmetry: SOP primarily restricts reading, not sending. A cross-origin form submission still reaches the server, which is exactly why CSRF defences are still required.

Choosing the right cross-origin mechanism

Need	Use
Read a cross-origin API response in JS	CORS (`Access-Control-Allow-Origin`)
Send messages between two windows/iframes	`postMessage` with a strict `targetOrigin`
Control who may embed your resources	CORP / COEP / `X-Frame-Options`
Legacy subdomain relaxation	`document.domain` — deprecated, avoid

Use the narrowest mechanism that solves the problem, and never widen CORS to * for credentialed or sensitive endpoints. This checker runs entirely in your browser — the URLs you enter are never sent anywhere.