πŸ”’ All processing happens in your browser. No data is sent to any server.
FREE

HTTP Cookie Inspector

← All Tools

Input

Session cookie Persistent Secure + HttpOnly SameSite=Strict Minimal

What is Cookie Inspector?

Cookie Inspector parses and analyzes HTTP Set-Cookie headers, cookie strings, and document.cookie values. Paste a Set-Cookie header or cookie string to see a breakdown of each cookie's name, value, domain, path, expiry, Secure flag, HttpOnly flag, and SameSite policy β€” with explanations of what each attribute means for security and caching behavior.

Cookies are key-value pairs stored in the browser that the server sets via Set-Cookie response headers and reads via the Cookie request header. Each cookie has attributes controlling scope, lifetime, and security: Domain specifies which hosts can access the cookie. Path restricts the cookie to specific URL paths. Expires or Max-Age sets lifetime (session cookie if omitted). Secure requires HTTPS. HttpOnly blocks JavaScript access (prevents XSS theft). SameSite (Strict/Lax/None) controls cross-site sending.

Cookie security matters significantly: a stolen session cookie gives an attacker the same access as the victim. HttpOnly prevents XSS attacks from stealing cookies via document.cookie. Secure prevents cookie transmission over HTTP. SameSite=Strict prevents CSRF by not sending cookies on cross-site requests. For session cookies: always use Secure + HttpOnly + SameSite=Lax (or Strict). The __Host- prefix enforces Secure + no Domain attribute + Path=/ for extra security.

How to Use

  1. Paste a Set-Cookie header value (the part after 'Set-Cookie: ') into the input.
  2. Or paste a document.cookie string with semicolon-separated name=value pairs.
  3. View the parsed breakdown with color-coded security indicators (green = secure, yellow = caution, red = insecure).
  4. Click 'Explain security' to get a plain-English assessment of the cookie's security configuration.
  5. Use the 'Cookie builder' tab to create a valid Set-Cookie header from scratch.

Examples

Parse session cookie

Result: sessionId=abc123; Path=/; Secure; HttpOnly; SameSite=Lax β†’ parsed with security assessment

Detect missing security flags

Result: auth_token=xyz; β†’ MISSING Secure, HttpOnly, SameSite β€” marked as insecure

Decode JWT in cookie

Result: access_token=eyJhbGc... β†’ base64 decoded and displayed as JWT header/payload

Frequently Asked Questions

What is the difference between HttpOnly and Secure cookie flags?

HttpOnly means the cookie cannot be accessed via JavaScript's document.cookie API β€” it's only sent in HTTP requests. This prevents XSS attacks from stealing the cookie. Secure means the cookie is only sent over HTTPS connections, never over HTTP. Both flags are security hardening β€” use both for session cookies and authentication tokens. A cookie without HttpOnly can be stolen by any JavaScript running on the page, including third-party scripts.

What is SameSite and why does it matter?

SameSite controls whether cookies are sent on cross-site requests β€” requests where the top-level domain of the page doesn't match the cookie's domain. Strict: only sent on same-site requests (clicking an external link to your site won't include the cookie). Lax: sent on same-site requests and top-level navigation GET requests (clicking a link). None: always sent, requires Secure flag. SameSite=Lax is the browser default since 2020, protecting against CSRF attacks.

What is the difference between session cookies and persistent cookies?

Session cookies have no Expires or Max-Age attribute β€” they're deleted when the browser tab/window is closed (or when the session ends, depending on browser settings). Persistent cookies have an Expires date or Max-Age in seconds and survive browser restarts. 'Remember me' features use persistent cookies with long lifetimes (30-90 days). Security consideration: shorter-lived cookies limit the damage window if a cookie is stolen.

What is the __Host- cookie prefix?

Cookie prefixes are a security mechanism. __Host- prefix (e.g., __Host-session=abc) enforces three requirements: the cookie must have the Secure flag, must not have a Domain attribute (so it's scoped to the current host only, not subdomains), and must have Path=/. This prevents cookie injection attacks where a subdomain sets cookies for the parent domain. __Secure- (simpler) just requires the Secure flag.

How are third-party cookies used and why are they being blocked?

Third-party cookies are set by a domain other than the one the user is visiting β€” typically ad networks, analytics, and social buttons. When you visit site A which loads ad scripts from adnetwork.com, adnetwork.com sets a cookie in your browser. When you later visit site B which also loads adnetwork.com, that cookie is sent β€” revealing that you visited both sites. Chrome is phasing out third-party cookies (Privacy Sandbox). Firefox and Safari already block them by default.

Related Tools