Cookie analyzer. Set-Cookie audit, tracker check.
Paste a Set-Cookie header from your server response, or load the cookies from this page. We parse each, audit the Secure / HttpOnly / SameSite / Partitioned flags, detect known trackers, and give a security verdict per cookie.
Paste Set-Cookie response headers (one or many) or click "load this page's cookies" for a live read of digitalheroes.co.in cookies. Each cookie gets parsed for name, domain, path, expiry, and the four security flags — plus a per-cookie verdict and known-tracker classification.
How do I get Set-Cookie headers?
- curl:
curl -I https://example.com— Set-Cookie lines in the headers. - DevTools: F12 → Network → click document request → Response Headers → copy each Set-Cookie line.
- Cookie string: open the target site, F12 → Console → type
document.cookie→ copy. (Different format — name=value pairs separated by semicolons. Toggle the parser mode below.)
Sources used
- RFC 6265 — HTTP State Management (cookies) canonical spec
- RFC 6265bis draft — current SameSite + cookie-prefix updates
- MDN Set-Cookie header reference — every attribute documented
- OWASP Session Management Cheat Sheet — Secure / HttpOnly / SameSite hardening
- web.dev SameSite cookies guide — Lax / Strict / None behavior
No data is sent to any external service. Parsing runs entirely in your browser. The "read current document" mode reads document.cookie locally and never transmits it. The source links above are reference documentation only.
Privacy: parsing happens in your browser. Nothing is sent or logged.
Four cookie flags. Each prevents a class of attack.
Secure. Cookie is only sent over HTTPS. Without Secure, a cookie set on an HTTPS response can leak when the user later hits an HTTP page on the same domain — the network attacker reads it. Default for every cookie on an HTTPS site. The cost of forgetting: session-token leak in the clear over public WiFi.
HttpOnly. Cookie is not readable by JavaScript via document.cookie. Prevents XSS-based session theft — an attacker who injects a script into your page can't steal the auth cookie because the browser hides it. Required for session and auth cookies; tracking cookies often skip it because they need JS access. The combination of HttpOnly auth cookies + Content Security Policy is the strongest XSS-defense layer.
SameSite. Controls cross-site request behavior. Strict = cookie never sent on cross-site requests (strongest CSRF protection). Lax = cookie sent on same-site + safe cross-site top-level GETs (the modern default). None = cookie sent on all cross-site requests (requires Secure and is now restricted by Chrome's third-party-cookie phase-out). Set Lax or Strict on every cookie; only use None for legitimate third-party embeds.
Partitioned (CHIPS). Cookies Having Independent Partitioned State — the modern third-party-cookie replacement. Partitioned cookies are keyed by both the third-party domain AND the top-level site. So an embedded payment widget gets a different cookie store on different host sites — preserves the legitimate use case of third-party cookies while killing cross-site tracking. Required for surviving Chrome's third-party-cookie deprecation. Google's CHIPS guide has the full spec.
Four jobs this tool covers.
Job 1: Pre-launch security audit. Before pushing a new auth flow or session system live, capture the Set-Cookie response from the auth endpoint, paste here. Verify Secure + HttpOnly + SameSite are set on the session cookie. The single most-common preventable security gap is missing one of these on the session cookie. Fix in your framework's cookie config (Express session middleware, Django settings, ASP.NET options).
Job 2: Tracker inventory for cookie banner. GDPR / ePrivacy require disclosing every tracker. Click "load this page's cookies" on each major page of your site, paste here, get the named-tracker classification. Build the cookie-banner disclosure list from the tool's output. Pair with our Tech Stack Detector for the script-side tracker inventory.
Job 3: Vendor / partner integration audit. Before integrating a third-party widget (chat, video, payment), audit the cookies it sets. Cookies missing Partitioned will become problematic as Chrome continues third-party-cookie phase-out. Ask the vendor to ship the Partitioned attribute or plan for the integration to break.
Job 4: Diagnose 'login doesn't persist' bugs. User reports that login works but they get logged out on the next page. Likely a SameSite=Strict cookie on a redirect-from-auth-provider flow, or a missing Domain attribute restricting the cookie to a sub-domain. Paste the Set-Cookie response, audit the flags. The fix is usually a one-attribute change in the auth library config.
Six questions users ask.
What flags should every cookie have?
For HTTPS-served sites, three flags are non-negotiable on session and auth cookies: Secure (only sent over HTTPS), HttpOnly (not readable from JavaScript — prevents XSS-based session theft), SameSite=Lax or Strict (prevents CSRF attacks where another site triggers a request that includes your cookies). Tracking and analytics cookies often skip HttpOnly because they need to be readable by JS, but should still set Secure + SameSite. The most common audit failure is SameSite missing — Chrome treats missing as SameSite=Lax now (the safe default), but explicitly setting it is best practice.
What's SameSite=Lax vs Strict vs None?
Strict: cookie sent only on same-site requests. Strongest CSRF protection but breaks single-sign-on flows where the user lands from another site authenticated. Lax: cookie sent on same-site requests + safe cross-site top-level GETs (link clicks). The modern default — protects against CSRF while preserving common navigation. None: cookie sent on all cross-site requests. Required for embedded third-party content (iframes, analytics scripts) that need cookies. SameSite=None requires Secure flag and is now blocked by default in many tracking-cookie contexts as part of third-party-cookie phase-out.
What's the Partitioned attribute?
Partitioned (CHIPS — Cookies Having Independent Partitioned State) is the modern replacement for third-party cookies. With Partitioned, a third-party cookie is keyed by both the third-party domain AND the top-level site that loaded it — so the same third-party script gets a different cookie store on different sites. Maintains the legitimate use cases of third-party cookies (embedded video player, payment widget) while preventing cross-site tracking. Required by Chrome's third-party cookie deprecation rollout. Part of the modern privacy-aware web.
Which trackers does it detect?
~25 common tracker patterns: Google Analytics (_ga, _gid, _gat), Meta Pixel (_fbp, _fbc), Hotjar (_hjid, _hjSession), Microsoft Clarity (_clck, _clsk), Mixpanel (mp_*), Amplitude (amp_*), Heap (_hp2_*), Segment (ajs_*), Klaviyo (__kla_id), HubSpot (hubspotutk, __hssrc), Intercom (intercom-*), Pendo (_pendo_*), Fullstory (FullStory_*), Optimizely (optimizelyEndUserId), and a few more. The detector also flags catch-all session/auth cookies (sessionId, JSESSIONID, ASP.NET_SessionId, PHPSESSID) so you can audit those for the right security flags.
Can I read cookies from a different domain?
No, browser security model isolates cookies per domain. JavaScript on this page can only read cookies set by digitalheroes.co.in. To audit cookies on a different domain, paste the Set-Cookie response header from the target server (get it via curl -I or DevTools Network tab) into the input above. Or visit the target site and run document.cookie in DevTools console, then paste the output here in 'cookie string' mode.
Is the cookie data I paste sent anywhere?
No. Parsing happens entirely in your browser. The page is static HTML; the only network request is the initial page load. Safe for cookies containing session IDs, auth tokens, or any sensitive value — paste them here without worrying about exfiltration.
Published .