Check and decode cookies for any URL. Free cookie checker that parses Set-Cookie headers, decodes values, and validates Secure, HttpOnly, and SameSite attributes.
Cookies control sessions, personalization, analytics, and ad tracking across the web. A single misconfigured cookie can break authentication, leak sensitive data to third-party scripts, or silently fail on browsers that enforce strict SameSite policies. The problem is that cookies are invisible during normal browsing. You set them in response headers and hope they work.
Without a cookie checker, debugging means opening browser DevTools, navigating to the Application tab, finding the domain, and manually inspecting each cookie's attributes. For cookies set by a URL you do not control, like an API endpoint or a third-party redirect, you need to intercept the HTTP response headers before the browser processes them. That is slow, manual, and easy to miss.
This cookie checker solves both problems. Enter a URL to fetch all Set-Cookie headers from the server response, or paste raw cookie data to parse and decode it instantly. The tool validates security attributes, flags missing Secure and HttpOnly flags, checks SameSite configuration, and decodes URL-encoded cookie values so you can see exactly what each cookie contains.
The tool has two modes. Use whichever matches your workflow.
document.cookie string from the browser console, or a Cookie: request header.The Parse Headers mode runs entirely client-side. Nothing is sent to any server. Use it when you already have cookie data copied from DevTools, curl output, or server logs.
The Set-Cookie header is the HTTP response header that tells browsers to store a cookie. Every time a server wants to set or update a cookie, it sends one Set-Cookie header per cookie. A single HTTP response can include multiple Set-Cookie headers.
The header contains the cookie name and value, followed by optional attributes separated by semicolons. Here is a typical example:
Set-Cookie: session_id=abc123def456; Path=/; Domain=.example.com; Expires=Thu, 01 Jan 2027 00:00:00 GMT; Secure; HttpOnly; SameSite=Lax
This cookie checker parses every part of that header: the name (session_id), the value (abc123def456), and each attribute (Path, Domain, Expires, Secure, HttpOnly, SameSite). It then validates the combination against current browser security requirements.
Every cookie attribute controls a different aspect of how the browser stores and sends the cookie. Here is what each one does and why it matters:
| Attribute | Values | What it controls |
|---|---|---|
| Secure | Flag (no value) | Cookie is only sent over HTTPS connections. Without this flag, cookies are sent in plaintext over HTTP, making them vulnerable to interception. |
| HttpOnly | Flag (no value) | Cookie is not accessible via document.cookie in JavaScript. This prevents XSS attacks from stealing session cookies. Essential for any cookie that stores authentication tokens. |
| SameSite | Strict, Lax, None | Controls whether the cookie is sent with cross-site requests. Strict only sends on same-site requests. Lax allows top-level navigations. None sends on all requests (requires Secure flag). |
| Domain | Hostname | Specifies which hosts can receive the cookie. If set to .example.com, all subdomains receive it. If omitted, the cookie is only sent to the exact host that set it. |
| Path | URL path | Restricts the cookie to a specific URL path. A cookie with Path=/api is only sent for requests under /api/. Defaults to the path of the URL that set the cookie. |
| Expires | Date string | Sets the cookie's expiration date. After this date, the browser deletes the cookie. If neither Expires nor Max-Age is set, the cookie is a session cookie and is deleted when the browser closes. |
| Max-Age | Seconds | Sets the cookie's lifetime in seconds from the current time. Max-Age=3600 means the cookie expires in one hour. Takes precedence over Expires when both are set. |
This cookie checker validates each attribute and flags combinations that violate browser requirements, like setting SameSite=None without the Secure flag (Chrome, Firefox, and Safari all reject this).
Browsers have tightened cookie security significantly since 2020. Chrome, Firefox, and Safari all enforce stricter defaults, and cookies that worked five years ago may silently fail today. Here are the practices that matter:
SameSite=Lax when the attribute is missing, but explicit is better than implicit. Use Strict for session cookies when cross-site access is not needed. Use Lax for cookies that need to survive top-level navigations (like login redirects). Use None only when cross-site sending is genuinely required (embedded iframes, third-party widgets), and always pair it with Secure.Domain=.example.com sends the cookie to every subdomain, including potentially compromised ones. If the cookie is only needed on app.example.com, omit the Domain attribute entirely so the browser restricts it to the exact origin.Max-Age measured in hours or days, not years. Long-lived cookies increase the window for session hijacking. Use Max-Age=0 or a past Expires date when you need to delete a cookie.These are the issues this cookie checker catches most often:
; Secure to every Set-Cookie header. In Rails, set config.session_store :cookie_store, secure: Rails.env.production?. In Express, set secure: true in cookie options.SameSite=None with Secure. If your site does not need cross-site cookie access, switch to SameSite=Lax and remove None.session_id, _session, or similar lacks HttpOnly, any XSS vulnerability can steal the session. Fix: add ; HttpOnly to the Set-Cookie header for all session-related cookies.Domain=.example.com when the cookie is only needed on www.example.com. This exposes the cookie to every subdomain, including staging environments and potentially compromised subdomains. Fix: omit the Domain attribute or set it to the specific subdomain.Max-Age or Expires.Max-Age=0 is a deletion instruction, not a bug. But if you see unexpired cookies alongside deletion headers for the same name, you may have a race condition where the cookie is set and immediately deleted.The SameSite attribute is the most misunderstood cookie setting. It controls cross-site request behavior, and getting it wrong breaks login flows, embedded widgets, or payment integrations. Here is what each value does:
| Value | Sent on cross-site requests? | Use when |
|---|---|---|
| Strict | Never | Maximum CSRF protection. Good for session cookies on sites that do not rely on cross-site navigation (like inbound links from emails maintaining the session). |
| Lax | Only on top-level navigations (GET) | The browser default since 2020. Best balance of security and usability. Blocks CSRF on POST but allows users to stay logged in when clicking links from other sites. |
| None | Always (requires Secure) | Required for cookies used in cross-site iframes, third-party widgets, OAuth flows, and payment processors that redirect through intermediary domains. |
If you are unsure, start with SameSite=Lax. It handles the vast majority of use cases correctly. Only use None when your cookie genuinely needs to be sent on cross-origin requests, and always add Secure alongside it. This cookie checker flags any SameSite=None cookie that is missing the Secure flag.
Enter the URL into this cookie checker and click Check Cookies. The tool fetches the page server-side and extracts all Set-Cookie headers from the HTTP response. You see every cookie the server sets, including HttpOnly cookies that are hidden from document.cookie in the browser console.
Check URL mode fetches the page from our server and reads the Set-Cookie headers from the live HTTP response. Parse Headers mode takes cookie data you have already copied (from DevTools, curl output, or server logs) and parses it client-side in your browser. Both give you the same structured output and security validation.
Yes. Cookie values are often URL-encoded (spaces become %20, special characters become percent-encoded sequences). This cookie decoder shows both the raw value and the decoded value side by side. If the value contains JSON, base64, or JWT data, decoding makes the contents readable.
The URL checker fetches the page as an anonymous visitor, so it only sees cookies set on the initial response. If you need to inspect cookies from an authenticated session, use the Parse Headers mode: copy the cookie data from your browser's DevTools (Application > Cookies or Network > Response Headers) and paste it into the parser.
Some websites only set cookies after user interaction (clicking a consent banner, submitting a form, or triggering JavaScript). Since the URL checker fetches the initial page response without executing JavaScript or interacting with the page, those cookies are not captured. The initial HTTP response itself may set zero cookies. This is normal for static sites and sites that defer cookie setting to client-side JavaScript.
Browsers require that any cookie with SameSite=None also has the Secure flag. Without Secure, the cookie is silently rejected. This combination was valid before 2020, but Chrome, Firefox, and Safari now enforce this rule. If this checker flags this issue, add ; Secure to the Set-Cookie header or change SameSite to Lax.
No. The URL is sent to our server to fetch the page on your behalf (browsers cannot make cross-origin requests to arbitrary URLs), but we do not store the URL or the cookie data. The Parse Headers mode runs entirely in your browser, and no data leaves your machine.
An HttpOnly cookie cannot be read or modified by JavaScript running on the page. The browser sends it with HTTP requests but blocks access via document.cookie. This is critical for session cookies because it prevents XSS attacks from stealing the session token. If an attacker injects malicious JavaScript into your page, they cannot exfiltrate HttpOnly cookies.
If you are inspecting cookies, you are likely debugging HTTP responses or validating how your site presents itself to browsers and bots. These tools handle related tasks:
Structured page data instead of raw HTML. Your agent processes less, decides faster, and costs less to run.