concept Frontend & browsers
HTTP cookies
An HTTP cookie is a small name/value state item delivered in `Set-Cookie` and potentially returned in later `Cookie` request headers.
What it means
An HTTP cookie is a small name/value state item delivered in Set-Cookie and potentially returned in later Cookie request headers. Whether it is stored or sent depends on attributes and user-agent policy. Scope (Domain, host-only and Path), transport (Secure), script visibility (HttpOnly) and request context (SameSite) answer different questions. A cookie is not an HTTP cached page, and a cookie value is not automatically proof of a valid authenticated session.
Try it
Simulation — use a virtual cookie jar. Start with a host-only cookie for app.example.com; switch the request to www.example.com to see that the host-only cookie is not sent. Try a domain cookie, a Secure cookie over HTTP, an HttpOnly cookie and SameSite Lax in top-level versus subresource requests. A SameSite=None cookie without Secure is rejected in this explicit browser-like fixture. Reset clears the virtual jar and request context.
Virtual cookie jar
Set one synthetic cookie and test if a request sends it and a script can read it.
Eligibility requires matching host, path, transport and explicit SameSite context. HttpOnly prevents script reading but does not exclude eligible HTTP requests.
| Observation | Model value |
|---|---|
| Stored? | Yes |
| Host matches? | true |
| Path matches? | true |
| Scheme permitted? | true |
| SameSite permits? | true |
| Request Cookie header? | none |
| Script view | Not readable / not inspected |
Local, bounded educational fixture. No DNS, mail, certificate, network, socket or external request is performed.
About this model
The jar exists only in component state, not document.cookie, storage or external requests. The model covers host/domain, path, Secure, HttpOnly and explicit SameSite contexts; browsers can enforce further policies, especially third-party restrictions.
See the article’s protocol sources and model limits. The scene does not alter a real system.
How the mechanism works
Servers send a Set-Cookie header with attributes; user agents enforce storage restrictions and decide on later inclusion. A host-only cookie is scoped to its origin host rather than sibling subdomains. A permitted Domain attribute can broaden subdomain eligibility but must satisfy domain-matching rules. A cookie Path is a request-path filter, not a general confidentiality boundary. Secure restricts sending to secure contexts; HttpOnly prevents access through common document-cookie interfaces but does not stop eligible cookies from being sent with HTTP requests.
SameSite limits cross-site request inclusion based on the declared mode and navigation context. In this fixture, explicit Lax allows a cross-site top-level safe GET but not a cross-site subresource. Explicit None needs Secure under modern cookie rules. User agents may also block third-party cookies, partition state, enforce prefixes, expiration and size limits differently. The model does not silently assume identical browser defaults.
Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.
In practice
When debugging a login or personalization workflow, inspect developer tools in a controlled test account without transmitting session tokens to support staff. Compare response Set-Cookie, cookie storage outcome, request host/path/scheme and the presence of Cookie on a subsequent request. Test privacy settings and embedded contexts separately. Stop before weakening Secure/HttpOnly flags or widening Domain solely to make one request work; identify the intended session trust boundary and rollback any unsupported change.
Limits and common mistakes
The widget never accesses document.cookie, LocalStorage, third-party services or a live browser's cookie jar. It represents one invented cookie with explicit context choices; this is not a conformance test for any particular browser version, nor legal or regulatory privacy advice.
Key takeaways
Cookie storage, eligibility for a request and script visibility are separate decisions. Host-only scope, path, Secure and SameSite determine request attachment, while HttpOnly prevents script reading of an otherwise eligible cookie. Inspect the explicit browser and request context; do not infer third-party behavior from the teaching jar.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Does HttpOnly stop the browser from sending the cookie?
No. HttpOnly restricts access from document-level scripts; an otherwise eligible HTTP request may still include the cookie.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.