Paste a cookie or Set-Cookie header and analyze it instantly: Secure, HttpOnly, SameSite, expiry, size. Scored findings with CWE refs. Free, in-browser.
This free cookie analyzer takes a raw cookie string or a full Set-Cookie response header, parses every attribute, and returns a scored security and privacy assessment of what that cookie actually does. Paste one cookie or a whole block of them, press Analyze, and you get a per‑cookie breakdown: which flags are set, which are missing, what each omission exposes you to, the CWE and OWASP Top 10 references for the finding, and a concrete remediation for each one.
It runs entirely in your browser. Session identifiers, authentication tokens and customer data pasted here are parsed by JavaScript on your own machine and never transmitted, which is what makes it safe to analyze a real production cookie captured from DevTools rather than a sanitised example.
One thing to be clear about up front: this is a cookie string analyzer, not a website crawler. You paste the cookie; it does not visit a URL and enumerate what that site sets. That makes it the right tool when you have a header in hand — from DevTools, a proxy capture, a curl trace, or your own Set-Cookie source code — and want an immediate verdict on it.
Each cookie is run through eight independent checks, and every finding is graded critical, high, medium, low or informational.
Without the Secure attribute a cookie is transmitted over plain HTTP as well as HTTPS, exposing it to network interception and to downgrade attacks. On a session or authentication cookie the analyzer grades this critical and cites CWE‑614; on a preference cookie it is a medium finding.
HttpOnly hides a cookie from document.cookie, which is the difference between a cross‑site scripting bug that defaces a page and one that steals every logged‑in session. Missing HttpOnly on a session or auth cookie is graded high and mapped to CWE‑1004.
Three distinct cases are reported. A completely missing SameSite is a high finding (CWE‑352, CSRF). SameSite=None without Secure is critical — modern browsers reject that combination outright, so the cookie will silently fail to set. SameSite=None with Secure is a medium note that the cookie travels on cross‑site requests by design and should be reviewed. For context: Strict withholds the cookie on every cross‑site navigation, Lax (the browser default when the attribute is absent) sends it on top‑level GET navigations only, and None sends it everywhere.
A leading dot such as Domain=.example.com shares the cookie with every subdomain, so a compromised marketing subdomain can read your application’s session cookie — flagged medium, CWE‑565. Attempting to set a cookie on a public suffix such as .com is flagged critical, because browsers reject it.
Path=/ makes the cookie available to every route on the host. That is normal for session cookies but worth narrowing for anything scoped to one area of the app.
The analyzer computes the real lifetime, tells you whether the cookie is a session cookie or persistent, flags cookies whose expiry is already in the past (they will be deleted immediately), and flags lifetimes beyond one year as a privacy concern under GDPR and CCPA data‑minimisation expectations.
Browsers cap individual cookies at roughly 4 KB (4096 bytes in Chrome and Firefox, 4093 in Safari). Anything above that is flagged high, because it will be silently dropped; anything above 2 KB is flagged as a performance concern, since the cookie is re‑sent on every single request to the origin.
The value is scanned for signs of sensitive data stored client‑side — passwords, national identifiers, card numbers, API keys and secrets — each graded critical (CWE‑312). A separate heuristic checks whether a value named like a token looks unencrypted rather than Base64, hex or JWT‑shaped.
Every cookie is classified from its name into one of seven categories — session, authentication, analytics, advertising, preference, tracking, or unknown — and that classification changes how strictly the flags are judged. A missing Secure flag on PHPSESSID or access_token is a critical failure; the same omission on a theme preference is a minor one. Classification also matters for privacy: _ga, _gid, _fbp and _gcl are recognised as analytics and advertising cookies, which in most jurisdictions require consent before they are set.
Two independent scores out of 100 are produced. The security score starts at 100 and deducts for each finding by severity (30 for critical, 20 for high, 10 for medium, 5 for low). The privacy score penalises tracking, advertising and analytics purposes, multi‑year lifetimes, cross‑site SameSite=None usage, and subdomain‑wide scope. A cookie can score well on security and badly on privacy — a perfectly flagged two‑year advertising identifier is exactly that case.
Set-Cookie line from the response headers — or open Application → Cookies and read the attributes there.sessionid=abc123; Secure; HttpOnly; Path=/; SameSite=Lax; Max-Age=3600, or the full header including the Set-Cookie: prefix. Put each cookie on its own line to analyze several at once.A Load Example button fills in a well‑configured session cookie alongside a long‑lived analytics cookie, which is a useful side‑by‑side illustration of how differently the two score.
Take Set-Cookie: sessionid=abc123; Path=/. The name matches the session pattern, so the analyzer classifies it as a session cookie and judges it strictly. It reports four issues: missing Secure (critical — the session identifier will traverse plain HTTP), missing HttpOnly (high — any XSS on the site can read it), missing SameSite (high — CSRF exposure), and site‑wide Path=/ (low). Add the three missing attributes — Set-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly; SameSite=Lax — and the same cookie comes back with only the low‑severity path note. That is the whole workflow: paste, fix, re‑paste, confirm.
Cookies are one layer of a site’s HTTP security posture. Once the flags are right, check the response headers around them with the security headers analyzer. If the cookie carries a JSON Web Token, inspect its claims and expiry with the JWT decoder, and use the URL encoder and decoder to unpick percent‑encoded cookie values.
It parses a cookie string or Set-Cookie header, extracts every attribute, and reports which security flags are present or missing, how long the cookie lives, how widely it is scoped, how large it is, and whether its value looks like it contains sensitive data — with a severity, a CWE reference and a fix for each finding.
No — this tool analyzes cookie strings you paste rather than crawling a site. Copy the cookies from your browser’s DevTools (Application → Cookies, or the Set-Cookie response headers in the Network tab) and paste them here, one per line.
No. Parsing, analysis and scoring all run in your browser. Nothing is uploaded, logged or stored, so real session identifiers and access tokens can be analyzed safely.
Strict never sends the cookie on a cross‑site request, including when a user follows a link from another site. Lax — the browser default when the attribute is absent — sends it on top‑level GET navigations but not on cross‑site POSTs, iframes or background requests. None sends it on every cross‑site request and is only accepted alongside Secure.
Without HttpOnly, any JavaScript running on the page — including injected script from a cross‑site scripting flaw or a compromised third‑party tag — can read the cookie via document.cookie. On a session cookie that turns a contained XSS bug into full account takeover, which is why the analyzer grades it high (CWE‑1004).
About 4 KB per cookie (4096 bytes in Chrome and Firefox, 4093 in Safari), with browsers also limiting the number of cookies per domain. The analyzer flags anything over 4093 bytes as likely to be rejected and anything over 2048 bytes as a performance problem, since cookies are re‑sent on every request.
Yes. Put each cookie or Set-Cookie header on its own line and every one is parsed and scored separately, with its own card and findings list.
Yes — the full analysis, including every finding and both scores, exports as JSON for tooling or as CSV for spreadsheets and audit documentation.
The security score measures how well the cookie is protected against interception, theft and CSRF. The privacy score measures how intrusive it is — its purpose, lifetime, cross‑site reach and subdomain scope. A cookie can be technically well configured and still score poorly on privacy.
Cookie analysis examines HTTP cookies set by websites to understand data collection practices, security configurations, and privacy compliance. Cookies are small text files stored in browsers that track sessions, preferences, authentication state, and user behavior. Analyzing them reveals what data a website collects, how long it persists, and whether proper security flags are set.
With privacy regulations like GDPR, CCPA, and ePrivacy Directive requiring informed consent for non-essential cookies, understanding cookie behavior is a compliance necessity. Security teams also analyze cookies to ensure session tokens are protected against theft through XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery) attacks. A cookie analyzer provides a systematic view of all cookies, their attributes, and potential issues.
Cookies are set by servers using the Set-Cookie HTTP response header and sent back by browsers with every subsequent request. Key attributes control cookie behavior and security:
| Attribute | Purpose | Security Impact |
|---|---|---|
| Name=Value | The cookie data | Contains session IDs, preferences, tracking IDs |
| Domain | Which domains receive the cookie | Overly broad domains expose cookies to subdomains |
| Path | URL path scope | / sends cookie with all requests |
| Expires/Max-Age | When the cookie is deleted | Session vs. persistent cookie |
| Secure | Only sent over HTTPS | Prevents interception on HTTP connections |
| HttpOnly | Not accessible via JavaScript | Prevents XSS-based cookie theft |
| SameSite | Cross-site request policy | Strict, Lax, or None; mitigates CSRF |
| Partitioned | CHIPS (third-party partitioning) | Limits cross-site tracking |
Cookie categories for privacy compliance:
What are HTTP cookies?
HTTP cookies are small data pieces stored by browsers, sent with every request to same domain.
Used for: session management (login state), personalization (preferences), tracking (analytics, ads).
Set via Set-Cookie header or JavaScript document.cookie.
Contains: name, value, expiration, domain, path, security flags.
Types: session cookies (temporary), persistent cookies (long-lived), first-party (same domain), third-party (different domain).
GDPR requires consent for non-essential cookies.
What is the HttpOnly flag?
HttpOnly flag prevents JavaScript access to cookies via document.cookie.
Mitigates XSS attacks - stolen session cookies via script injection.
Example: Set-Cookie: sessionid=abc123; HttpOnly.
Cookie still sent in HTTP requests but hidden from client-side scripts.
Essential for authentication cookies.
Not bulletproof - XSS can still make authenticated requests (CSRF).
Use with: Secure flag, SameSite, CSP.
Check: browser DevTools Application tab shows HttpOnly column.
What is the Secure flag?
Secure flag ensures cookies only transmitted over HTTPS, never unencrypted HTTP.
Prevents eavesdropping on unsecured networks.
Example: Set-Cookie: token=xyz789; Secure.
Required for sensitive data (sessions, auth tokens, personal info).
Modern browsers require Secure for SameSite=None cookies.
Local development: use localhost (exempt) or HTTPS proxy.
All production cookies should use Secure flag.
HTTP sites cannot set Secure cookies.
What is SameSite attribute?
SameSite prevents CSRF attacks by controlling when cookies sent in cross-site requests.
Three values:
Example: Set-Cookie: id=123; SameSite=Strict.
Use Strict for sensitive actions (banking), Lax for general sites, None for third-party integrations (OAuth, payment).
Modern browsers default to Lax if omitted.
How to set cookie expiration?
Two attributes: Expires (specific date) or Max-Age (seconds from now).
Example: Expires=Wed, 21 Oct 2025 07:28:00 GMT or Max-Age=3600 (1 hour).
Session cookies: omit both attributes, deleted when browser closes.
Persistent cookies: set expiration.
Security: short-lived tokens (minutes-hours), long-lived remember-me (days-weeks).
Auto-renewal: refresh token before expiry.
Privacy: GDPR limits persistent cookie duration.
Use Max-Age (easier calculation).
First-party cookies:
set by visited domain (example.com on example.com).
Used for: sessions, preferences, analytics.
Third-party cookies:
set by different domain (ads.tracker.com on example.com).
Used for: cross-site tracking, retargeting, analytics.
Browser trends:
Safari/Firefox block third-party by default, Chrome phasing out 2024-2025.
Alternatives:
first-party data collection, server-side tracking, Privacy Sandbox.
GDPR:
requires explicit consent for non-essential cookies (both types).
Best practices:
HttpOnly flag (prevent XSS theft).
Secure flag (HTTPS only).
SameSite=Strict or Lax (prevent CSRF).
Short expiration (15-60 min).
Prefix: __Host- or __Secure- (enforces Secure + domain restrictions).
Cryptographic signing (HMAC-SHA256).
Regenerate session ID after login.
Clear cookies on logout.
Example:
Set-Cookie: __Host-sessionid=abc; Secure; HttpOnly; SameSite=Strict; Max-Age=3600.
What are cookie prefixes?
Cookie prefixes enforce security requirements:
__Secure- prefix requires Secure flag and HTTPS.
__Host- prefix requires: Secure flag, no Domain attribute (exact domain only), Path=/.
Example: __Host-token=xyz forces most restrictive settings.
Prevents: subdomain/related-domain cookie injection, downgrade attacks.
Browser enforces requirements - invalid combinations rejected.
Use __Host- for maximum security (auth tokens), __Secure- for general secure cookies.
Not widely adopted yet but recommended.
First-party cookies are set by the website you visit and are used for essential functions like login sessions. Third-party cookies are set by external domains (like ad networks) and track users across websites. Browsers are increasingly blocking third-party cookies for privacy.