You set a cookie on example.com and it mysteriously doesn't show up on shop.example.com. Or it turns up on a path where you didn't want it. Both come down to two attributes that decide the reach of a cookie: Domain and Path. Together they answer the question the browser asks before every request: does this cookie belong on this one?
Domain: which hosts get the cookie
The Domain attribute controls which hosts the browser will send the cookie to. There are two cases, and the default surprises people.
No Domain attribute (host-only). If you set a cookie without Domain, it becomes a host-only cookie, sent only to the exact host that set it. A cookie set by example.com with no Domain won't go to www.example.com or shop.example.com. Plenty of people expect the opposite, and it's a common source of "why am I logged out on the www version" bugs.
Domain set. If you set Domain=example.com, the cookie is sent to example.com and every subdomain: www.example.com, shop.example.com, api.example.com, and so on. You can only set Domain to your own domain or a parent domain, never a subdomain or an unrelated site. A page on shop.example.com can set a cookie for example.com, but not for google.com.
There's a hard limit at the top. You can't set Domain to a public suffix like .com or .co.uk, because that would let one site drop a cookie on every site beneath it. Browsers enforce this with a public suffix list, the same eTLD concept behind "same-site", so a cookie's reach stops at the registrable domain you actually own.
Path: which URLs get the cookie
The Path attribute narrows the cookie to a slice of your URLs. The browser sends it only when the request path matches the cookie's Path as a prefix, treating / as a directory separator.
With Path=/docs, the cookie is sent on /docs, /docs/, /docs/web, and anything deeper. It is not sent on /, on /docsets (similar spelling, different directory), or on /fr/docs. Set Path=/ and the cookie applies to the entire site, which is what most cookies want. MDN is blunt about one thing: Path is a scoping convenience, not a security boundary. Don't rely on it to hide a cookie from part of your own site, because any page under that path can read it anyway.
How Domain and Path scope a cookie
| Setting | Cookie is sent to |
|---|---|
| No Domain (host-only) | Only the exact host that set it |
| Domain=example.com | example.com and all its subdomains |
| Path=/ | Every path on the site |
| Path=/account | /account and everything under it |
Domain and Path work together
A cookie is sent only when both tests pass: the host matches the Domain rule and the request path matches the Path rule. That combination is how one site runs different cookies for different areas, say a cart cookie scoped to Path=/shop and an admin cookie scoped to Path=/admin. When two cookies share a name, the browser sends the one with the more specific (longer) path first.
One consequence trips people up when deleting cookies. To remove a cookie you have to send a matching Domain and Path with an expiry in the past. Get the scope wrong and you quietly set a second, differently scoped cookie instead of clearing the first, which is why a "logout" sometimes leaves a stale cookie behind.
Two things Domain and Path do not do. They don't consider the scheme, so an http and an https version of the same host share cookies unless you add Secure. And they don't cross to a different registrable domain, which is the boundary that separates first-party from third-party cookies. For that split, see first-party vs third-party cookies.
__Host- cookies forbid Domain on purpose
The hardened __Host- name prefix requires a cookie to omit Domain entirely and use Path=/. That forces the cookie to be host-only, so a sibling subdomain can't set a cookie your main site would trust. For the strongest scoping on a session cookie, that's the combination: no Domain, Path=/, Secure, and a __Host- name. See Secure and HttpOnly flags.
Scope, consent, and multiple domains
Scope has a direct consent consequence. A cookie set with Domain=example.com spreads across every subdomain, so a tracker set that way is collecting across your whole property and needs consent that covers all of it. Consent itself doesn't cross a registrable domain, though. Because the browser won't share cookies between example.com and example.co.uk, a visitor's choice stored in a cookie on one won't be visible on the other, which is why running a single banner across several domains takes deliberate setup. See cross-domain consent sharing.
When CookieBeam scans a site, it captures each detected cookie's Domain and Path alongside its category, so you can see whether a cookie is host-only or spread across subdomains, and which part of the site sets it. That inventory is what turns a vague "we use cookies" into a per-cookie record you can act on.
Checking scope in practice
In DevTools under Application then Cookies, the Domain and Path columns show each cookie's scope. A leading dot on a domain (.example.com) is the older way of writing "include subdomains" and behaves like a plain Domain=example.com today. If a cookie isn't showing up where you expect, this is the first place to look.
Related: how the Set-Cookie header works, the SameSite attribute, and session vs persistent cookies.