Read a sample cookie header

Set-Cookie: session=example-value; Path=/; Secure; HttpOnly; SameSite=Lax

• session=example-value is the cookie name and an illustrative value. A real session value may be sensitive; do not share it publicly.
• Path=/ means the cookie is eligible for requests to paths across this host. MDN cautions that Path controls where a cookie is sent; it is not a security boundary.
• Secure means the browser sends the cookie over HTTPS connections, not ordinary HTTP. It does not encrypt a value at rest or replace other protections.
• HttpOnly prevents scripts using document.cookie from reading the cookie. The browser can still attach it to matching HTTP requests.
• SameSite=Lax limits sending on many cross-site requests while allowing some top-level navigations to the cookie's site. Whether this fits a site's login or embedded feature depends on how that feature works.

What the three attributes tell you

Secure: transport condition

Look for Secure when checking whether a cookie is restricted to HTTPS. MDN notes an exception for localhost in some browsers, so treat this as a general behavior rather than an absolute rule for every development environment. A Secure flag alone does not say who can read a cookie on the device, how long it is kept, or what the site does with associated account data.

HttpOnly: JavaScript access

When HttpOnly is present, page scripts cannot read that cookie through document.cookie. This can reduce exposure of a session identifier to certain script attacks. It does not stop the browser from sending the cookie with requests that match its scope, and it is not a general statement that a site contains no tracking scripts.

SameSite: cross-site request behavior

Strict is the most restrictive of the three common values and limits sending to same-site contexts. Lax also permits some top-level navigations from another site. None permits cross-site sending; MDN says it must be paired with Secure. If SameSite is omitted, MDN describes Lax as the default, though browser behavior and compatibility details can vary. SameSite can help with cross-site request forgery defenses, but it is not a complete privacy or security policy.

How to inspect cookies in your browser

1. Open the browser's developer tools on the site you are reviewing. In Chrome, look in the Application panel; Firefox has a Storage Inspector. Names and layouts can change between browser versions.
2. Open the Cookies view for the current site and inspect the name, domain, path, expiry, Secure, HttpOnly, and SameSite columns when available. A cookie with HttpOnly may appear in developer tools even though page JavaScript cannot read it.
3. To see when a cookie is set or changed, inspect the page's network requests and look for a Set-Cookie response header. A Cookie request header shows cookies sent with that particular request.
4. Record only the attribute names and general purpose you can establish from site documentation. Avoid copying live cookie values: session cookies can function like credentials.

The browser may block, partition, or omit cookies based on its privacy settings and the request context. A view from one browser session is only a snapshot; it is not an inventory of every identifier or data flow on a service.

Do not infer purpose from flags alone

Cookies can support session management, preferences, or tracking. The same attributes can be used on cookies with different purposes, and a cookie without a tracking label is not necessarily harmless or necessary. To understand purpose, compare the cookie name and setting domain with the site's privacy or cookie notice, the feature you used, and the request that set it. Those clues still may not establish who receives or retains related data.

For the separate question of browser fingerprint signals, see the browser fingerprint self-check guide. For network visibility through a VPN, see what a VPN can and cannot hide.

Common questions

Does Secure mean the cookie value is encrypted everywhere?

No. Secure tells the browser to send it only over HTTPS connections, subject to browser-specific exceptions such as localhost. It does not describe encryption while stored on a device or the site's data handling.

Does HttpOnly stop the browser from sending a cookie?

No. It prevents page JavaScript from reading the cookie through APIs such as document.cookie. The browser can still attach it to matching requests.

Does SameSite=Lax block every cross-site request?

No. Lax limits sending on cross-site requests while allowing some top-level navigations to the cookie's site. Strict is more restrictive; None permits cross-site sending and must be paired with Secure.

Do cookie flags tell me whether a cookie tracks me?

No. The flags describe transport, script access, and request context. Cookies can support sessions, preferences, or tracking, so check the site's disclosures and the context in which the cookie is set.

Can developer tools show an HttpOnly cookie?

Browser developer tools can show cookie metadata even though page JavaScript cannot read an HttpOnly cookie. Avoid copying or sharing live values because session cookies may be sensitive.