Origin
/ˈɒrɪdʒɪn/
An origin is the triple of scheme + host + port. Two URLs are "same origin" when all three match. The browser uses origin as the boundary for security decisions: CORS, cookie scoping, localStorage partitioning, and the same-origin policy all hinge on it.
Examples
https://app.example.com ← origin: https + app.example.com + 443
https://app.example.com:443 ← same origin (default port)
http://app.example.com ← different (scheme: http)
https://api.example.com ← different (host)
https://app.example.com:8080 ← different (port)
https://app.example.com/path ← same (path doesn't matter)
Things people get wrong about origin
- Subdomains are different origins.
www.example.comandapi.example.comdon't share an origin. They share a "site" (used by some newer cookie attributes likeSameSite), but not an origin. - The path is not part of the origin.
example.com/aandexample.com/bare the same origin. - The default ports count.
https://example.comandhttps://example.com:443are the same;http://andhttps://are not. file://URLs are special. Most browsers treat eachfile://path as a different origin from every other, which is why loading local HTML and trying tofetch()usually fails.
Why the browser cares
Origin is the only practical answer to "which website is this code from?". JS running on app.example.com belongs to that origin; it gets to read that origin's cookies and storage, and only that origin's. When it tries to read something from another origin, the browser falls back on CORS rules to decide whether to allow it.
In CORS headers
The browser sends the requesting page's origin in the Origin header on cross-origin requests. The server replies with Access-Control-Allow-Origin echoing that origin (or * for "anybody") to authorize the response.
// Request from app.example.com
GET /api/users HTTP/1.1
Host: api.partner.com
Origin: https://app.example.com
// Response (server says "yes, that origin is allowed")
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json
…