Browsers key some behaviour to an "origin" and other behaviour to a "site". How does a browser compute a site, how does that differ from an origin, and name something keyed to each.

## Two granularities, deliberately The web has two units of grouping and they do different jobs. The **origin** is the strict one: scheme, host and port, compared component by component. It is the boundary for scripting and for storage — the thing the same-origin policy enforces. The **site** is the loose one: a family of hosts under one registrable domain, usually assumed to be run by one organisation. It exists because some questions — "is this navigation staying within one company's property?" — cannot be answered usefully at origin granularity, since a single company routinely spreads itself over dozens of subdomains. ## How a site is computed Start from the host and find its *public suffix*: the longest suffix under which anyone may register a name. Add exactly one label to the left of it, and you have the **registrable domain**, also written eTLD+1 (effective top-level domain plus one). The catch is that a public suffix is not simply the TLD. `co.uk`, `com.au`, `github.io`, `vercel.app` and thousands of others are public suffixes, because registration below them is open to unrelated parties. Browsers do not derive this — they ship the **Public Suffix List**, a curated data file, and consult it. ``` host = app.shop.example.com -> suffix com -> site example.com host = shop.example.co.uk -> suffix co.uk -> site example.co.uk host = alice.github.io -> suffix github.io -> site alice.github.io ``` That third line is the one that surprises people: two project pages on the same hosting domain are different sites, which is the entire point of listing the domain. Modern browsers also apply **schemeful same-site**: the scheme is folded into the comparison, so `http://example.com` and `https://example.com` are cross-site even though the host is identical. The port is never part of a site. ## Origin versus site, side by side | | origin | site | |---|---|---| | host | exact match | same registrable domain | | scheme | must match | must match (schemeful same-site) | | port | must match | ignored | Every same-origin pair is same-site. The reverse is not true, and that gap — same site, different origin — is where most real-world confusion lives. ## What is keyed to which **Origin-keyed:** `localStorage`, `sessionStorage` and IndexedDB partitions; the `Origin` request header; the target-origin check on cross-document messaging; the same-origin policy's own DOM-access decisions. Two subdomains of one company get *separate* storage and cannot script each other, however much they feel like one product. **Site-keyed (or host-keyed):** cookies are the big one. A cookie is scoped by host and path, is shared across ports, and whether it counts as first-party on a particular request is decided at site granularity. Browsers also partition several caches and storage areas by the *top-level* site, so the same embedded third party loaded under two different parent sites sees two different partitions. ## Why this bites in practice The most common surprise is a team that assumes "our subdomains share everything". They do share cookies if a cookie is deliberately scoped to the parent domain, but they do **not** share `localStorage`, `sessionStorage` or IndexedDB, and script on one cannot read the other's DOM. A token stashed in `localStorage` on `app.example.com` simply does not exist on `checkout.example.com`. The second surprise runs the other way. Because a site spans every subdomain, any host under your registrable domain is site-adjacent to your main app — a forgotten staging box, a marketing microsite, a customer-controlled vanity subdomain. That host cannot script your origin, but it is inside your site for anything decided at site granularity, including domain-scoped cookies. Getting an untrusted service onto its own registrable domain, rather than a subdomain of yours, is a meaningfully stronger separation than getting it onto its own origin. The third is the PSL itself. If you operate a platform that hands out subdomains to independent customers, submitting your domain to the Public Suffix List is what makes each customer subdomain its own *site* rather than all of them sharing yours.