Domain Context loading…
Current Hostname …
Protocol …
Is this host a PSL entry? …
Public Suffix / eTLD …
Registrable Domain (eTLD+1) …
Widest Allowed Cookie Domain
Cookie Inspector
0 cookies
NameValue
No cookies
Raw document.cookie:
(empty)
Set Cookie
Server-Side Cookie View (what the server receives in the Cookie request header)

document.cookie in JavaScript hides HttpOnly cookies for security. This panel makes a live fetch to the server and shows exactly what it receives — including HttpOnly cookies that are invisible above.

Guided Experiments

Goal: Prove foo.platter-app.dev cookies are invisible on bar.platter-app.dev.

  1. Navigate to foo.platter-app.dev
  2. Set a cookie — Name: from_foo, Value: hello_from_foo, Domain: (unset)
  3. Navigate to bar.platter-app.dev
  4. Check Cookie Inspector — from_foo is NOT there
Why? platter-app.dev is in the PSL private section, so browsers treat foo.platter-app.dev and bar.platter-app.dev as fully separate security origins — just like alice.github.io and bob.github.io. No cookies leak across the boundary.

Goal: Try to set a tracking cookie spanning all subdomains.

  1. Go to foo.platter-app.dev
  2. Set a cookie — Name: supercookie, Value: tracking_you
  3. Domain: platter-app.dev (the “PSL entry, REJECT” option)
  4. Click Set Cookie
  5. Result: Cookie Inspector shows 0 new cookies — browser silently rejected it
Why? The browser checks the PSL and refuses to set any cookie whose domain attribute matches a public suffix. Without this protection, foo.platter-app.dev could set a .platter-app.dev cookie that every other subdomain would send to the server — a classic cross-site tracking attack.

Goal: Set a cookie on platter-app.dev and check subdomain visibility.

  1. Navigate to platter-app.dev
  2. Set a cookie — Name: root_cookie, Value: im_root, Domain: (unset)
  3. Navigate to foo.platter-app.dev
  4. Result: root_cookie is NOT visible
Compare with non-PSL: On a normal domain like example.com, a cookie with domain=example.com would be visible on sub.example.com. But because platter-app.dev is itself a PSL entry, it has no “parent” to share cookies with, and subdomains cannot inherit from it.

Goal: Try to set a cookie for bar.platter-app.dev while on foo.platter-app.dev.

  1. Navigate to foo.platter-app.dev
  2. Set a cookie — Name: cross_attempt, Domain: bar.platter-app.dev
  3. Result: Cookie Inspector shows 0 new cookies
  4. Navigate to bar.platter-app.dev — also empty
Why? A page can only set cookies for its own host or an ancestor domain (up to but not including a PSL entry). foo.platter-app.dev cannot set cookies for bar.platter-app.dev — they share no common ancestor below the PSL boundary.

Goal: Observe the gap between document.cookie and the server’s Cookie header.

  1. Open browser DevTools → Application → Cookies
  2. Manually add a cookie with the HttpOnly flag checked
  3. Check the Cookie Inspector above — the cookie is absent
  4. Click Fetch in Server-Side Cookie View — the cookie appears
Why? HttpOnly is a server-set flag that instructs the browser to include the cookie in HTTP requests but never expose it to JavaScript. This prevents XSS attacks from stealing session tokens.
What is the PSL?

The Public Suffix List is a community-maintained catalog of all domain suffixes under which Internet users can directly register names. Originally created by Mozilla, it is now used by all major browsers, and many other tools (curl, Go's net/http, Python's tldextract, etc.).

Two sections
  • ICANN Section — standard TLDs: .com, .co.uk, .pvt.k12.ma.us
  • Private Section — company-specific entries: github.io, s3.amazonaws.com, platter-app.dev

platter-app.dev — the base domain of this sandbox — is listed in the private section.

Key terms
TermMeaningExample
eTLDEffective top-level domain (the PSL entry)platter-app.dev
eTLD+1One label to the left of the eTLD (registrable domain)foo.platter-app.dev
Host-only cookieNo domain attribute; bound to exact hostnameset on foo.platter-app.dev, stays there
How PSL protects cookies

Browsers enforce two PSL-based cookie rules:

  1. No PSL-entry cookies. document.cookie = "x=1; domain=platter-app.dev" is silently dropped if platter-app.dev is in the PSL.
  2. eTLD+1 isolation. foo.platter-app.dev and bar.platter-app.dev have different eTLD+1 values, so they cannot share cookies — even though they are served by the same server.
Real-world examples
DomainPSL entryEffect
alice.github.io github.io Cannot share cookies with bob.github.io
foo.platter-app.dev platter-app.dev Cannot share cookies with bar.platter-app.dev
shop.example.com com CAN share cookies with example.com (set domain=example.com)
evil.co.uk co.uk Cannot set domain=co.uk supercookie
Without the PSL (hypothetical attack)

If platter-app.dev were not in the PSL, foo.platter-app.dev could write document.cookie = "tracker=1; domain=.platter-app.dev". The browser would include that cookie on every request to every subdomain — allowing one tenant to track all others. The PSL makes this impossible.