// inspect cookie attributes in one click
Parse and inspect Set-Cookie headers instantly. View path, domain, expiry, SameSite, Secure, HttpOnly, and all cookie attributes. Free browser-based tool.
Set-Cookie header (everything after the colon)Ready to parse
Paste a Set-Cookie header and click ParseIn browser DevTools → Network tab, find a response with Set-Cookie header. Copy the value (not the key).
Paste the raw cookie string into the input field and click Parse Cookie.
All cookie attributes are displayed in a structured table with security warnings highlighted.
The Set-Cookie Parser breaks down HTTP cookie header strings into readable, structured attributes. Instead of manually splitting semicolons and guessing attribute meanings, this tool visualizes every field and flags potential security issues like missing Secure or HttpOnly flags.
Open browser DevTools (F12), go to the Network tab, click any request, open the Response Headers section. If the server sets cookies, you'll see one or more Set-Cookie lines. Copy the value after the colon.
Expires sets an absolute date/time for cookie expiry. Max-Age sets a relative number of seconds from the current time. If both are present, Max-Age takes precedence in modern browsers. A cookie with neither attribute is a session cookie and expires when the browser closes.
SameSite controls whether a cookie is sent with cross-site requests. Strict only sends cookies to the origin site. Lax (default in modern browsers) sends cookies on top-level navigation. None sends cookies on all cross-site requests but requires the Secure flag. Missing SameSite can expose apps to CSRF attacks.
The Secure attribute ensures the cookie is only transmitted over HTTPS connections. Without it, the cookie could be intercepted over insecure HTTP connections, exposing session tokens or sensitive data to man-in-the-middle attacks.
The HttpOnly flag prevents JavaScript from accessing the cookie via document.cookie. This protects against cross-site scripting (XSS) attacks that try to steal session tokens. Authentication cookies should almost always have this flag set.
No. All parsing is done entirely in your browser with JavaScript. The cookie string never leaves your device. There is no backend storage, logging, or analytics capturing your cookie values.
This tool parses one Set-Cookie header value at a time. If you have multiple cookies, parse them separately — each cookie is a separate Set-Cookie header in the HTTP response, not semicolon-separated in one header.
The Domain attribute specifies which hosts can receive the cookie. If set to example.com, subdomains like sub.example.com also receive it. If omitted, the cookie is only sent to the exact origin host. Be careful with overly broad domain settings.
A Set-Cookie parser is a tool that takes the raw value of an HTTP Set-Cookie response header and breaks it down into its individual components — the cookie name, value, and all associated attributes like Path, Domain, Expires, Max-Age, SameSite, Secure, and HttpOnly. Instead of manually reading and splitting semicolon-delimited strings, a parser presents each attribute in a clear, structured format.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer assets — worth checking out.
HTTP cookies are set by servers using the Set-Cookie response header. Each header contains a name-value pair followed by optional directives separated by semicolons. Understanding each attribute is essential for building secure web applications.
The Path attribute restricts which URL paths on the server can receive the cookie. For example, Path=/api means only requests to URLs starting with /api include the cookie. If omitted, it defaults to the path of the page that set the cookie. Using Path=/ makes the cookie available site-wide.
The Domain attribute specifies which hosts are allowed to receive the cookie. Setting Domain=example.com means the cookie is sent to example.com and all its subdomains. Omitting the Domain attribute restricts the cookie to the exact host only, which is generally more secure for sensitive cookies.
These two attributes control cookie lifetime. Expires accepts an absolute HTTP date/time string (e.g., Wed, 09 Jun 2026 10:18:14 GMT). Max-Age specifies a relative number of seconds from the current time. When both are present, Max-Age takes precedence in modern browsers. A cookie without either attribute is a session cookie — it persists only until the browser session ends.
The SameSite attribute controls how cookies behave in cross-site contexts. There are three values: Strict — cookie is never sent in cross-site requests; Lax — cookie is sent with top-level navigation (e.g., clicking a link) but not with background requests like images or iframes; None — cookie is sent in all cross-site contexts, but requires the Secure flag. Modern browsers default to Lax if SameSite is not specified.
The Secure attribute is a boolean flag that prevents the browser from transmitting the cookie over unencrypted HTTP connections. The cookie is only sent over HTTPS. This protects against network-level interception attacks. Any cookie that contains sensitive data like session tokens or auth credentials should always have the Secure flag.
The HttpOnly attribute prevents client-side scripts (JavaScript) from accessing the cookie via document.cookie. This is a critical defense against cross-site scripting (XSS) attacks. If an attacker injects malicious JavaScript into your page, cookies without HttpOnly can be stolen and used to hijack user sessions. Authentication and session cookies should always be HttpOnly.
Security audits frequently reveal recurring cookie configuration errors. The most critical include: missing the Secure flag on cookies transmitted over HTTPS; omitting HttpOnly from session cookies, leaving them vulnerable to XSS theft; using SameSite=None without the Secure flag (which browsers now reject); setting an overly broad Domain attribute that shares cookies with unintended subdomains; and setting very long Max-Age values on sensitive cookies without implementing server-side session expiry.
To find Set-Cookie headers in Chrome or Firefox DevTools: open DevTools with F12, navigate to the Network tab, filter by "Doc" or "XHR", click on any request to your backend, select the "Headers" tab in the detail panel, scroll to "Response Headers", and look for any set-cookie entries. The value after the colon is what you paste into this parser. You can also use Application → Cookies in Chrome DevTools to see cookies already stored for the current domain, though some attributes like HttpOnly are not fully visible there due to the security flag itself.
When reviewing cookies for a production web application, verify the following for each authentication or sensitive cookie: the Secure flag is present; HttpOnly is set; SameSite is explicitly set to Strict or Lax (avoid None unless you specifically need cross-site access); the Domain is as narrow as possible; the Expires or Max-Age is reasonable (not years into the future for session cookies); and no sensitive data is stored in the cookie value itself — use opaque session identifiers that reference server-side state.