Why is my cookie not being set?
Common causes are SameSite=None without Secure, a __Host- or __Secure- prefix whose rules are broken, a Domain the page cannot set, or a size over 4096 bytes. The decoder flags each of these.
COOKIE DECODER
Paste a Cookie request header or one or more Set-Cookie lines. Each cookie is decoded into its name, value shape, lifetime, scope, and cross-site behavior, and checked against the rules modern browsers actually enforce.
Loading the workbench.
About the Cookie decoder
How Can You Verify That Nothing Leaves This Browser?
You do not have to take our word that your cookies stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.
- Open your browser developer tools with
F12, orCmd+Option+Ion a Mac, and select the Network tab. - Reload the page and let it finish. You will see the page's own files, its web fonts, and one anonymous page-view request. Nothing has been typed yet, so none of them can contain your cookies.
- Click the clear icon in the Network tab so that the log is empty.
- Paste a Set-Cookie line and reveal its value.
- Look at the Network tab again. It is still empty. For extra proof, turn on offline mode after the page loads and every lane keeps working.
Only two things can add a line to that log, and neither carries your cookies. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.
2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.
What Is the Difference Between Cookie and Set-Cookie?
Set-Cookie is a response header: the server uses it to store one cookie, with attributes that control how long it lives and where it is sent. Cookie is a request header: the browser sends back every cookie that matches the request, as plain name=value pairs separated by semicolons, with no attributes at all.
The decoder detects which one you pasted. For a Cookie header it lists each cookie, flags duplicate names, and warns when the header grows past the 8 KB many servers accept. For Set-Cookie lines it decodes and audits every attribute.
What Does Each Attribute Do?
- Expires and Max-Age set the lifetime. Max-Age wins when both are present, and a zero or past value deletes the cookie. Without either, it is a session cookie.
- Domain widens the cookie to every subdomain. Leaving it out keeps the cookie host-only, which is safer.
- Path limits which URLs receive it. Without it, the default is the directory of the request URL.
- Secure keeps it off plain HTTP. HttpOnly hides it from page JavaScript.
- SameSite controls cross-site sending: Strict, Lax, or None, which requires Secure.
- Partitioned stores it separately per top-level site, and also requires Secure.
Which Rules Do Browsers Enforce?
- A cookie without SameSite is treated as Lax by Chrome, Edge, and Firefox.
- SameSite=None without Secure is rejected and never stored.
- Names starting with __Secure- need Secure; names starting with __Host- also need Path=/ and no Domain.
- Chrome caps any lifetime at 400 days, and browsers drop cookies over 4096 bytes.
- A Domain without a dot, such as a bare top-level domain, is rejected.
Cookies whose names look like sessions or auth tokens get stricter checks: a missing Secure or HttpOnly on those is a failure, not a suggestion.
How Are Cookie Values Shown?
Cookie values are usually sessions, so they are masked by default with a short prefix and the length. The decoder still describes the shape of each value without printing it: URL-encoded text, JSON with its key names, a JWT with its algorithm and claim names, a hex identifier with its bit length, base64, a UUID, or an Express signed cookie. A Reveal option shows the real value, and everything is wiped when you leave the tab.
What Other Lanes Are in the Decode Section?
- Header decoder: Paste raw request or response headers and get every header explained, with secrets masked.
- Cache-Control decoder: Cache-Control directives, freshness math for browser and CDN, and ETag revalidation.
- CORS checker: Describe a cross-origin request, paste the response, and get the browser's verdict.
- User-agent parser: Browser, engine, OS, device, and bot detection from a pasted User-Agent string.
Elsewhere in 2http: Security header audit, Request builder, Meta tag generator, HTTP status codes, MIME types, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.
Frequently Asked Questions
What does SameSite=Lax mean in practice?
The cookie is sent when a user follows a link to your site, but not on cross-site requests such as images, iframes, or fetch calls from another site. It blocks most cross-site request forgery.
Should a session cookie be HttpOnly?
Yes. HttpOnly stops page JavaScript from reading it, so a cross-site scripting bug cannot steal the session. Only cookies the front end must read should go without it.
Is my cookie value sent anywhere?
No. Decoding happens in this tab only. Values are masked on screen, never saved, and wiped when you leave the tab or press Wipe.