Developer Tool

Cookie Decoder

Decode cookie values locally in your browser. Parse Cookie headers, URL-decode values, detect base64 and JSON payloads, and inspect session tokens without sending data anywhere.

Web developers, QA engineers, and security researchers need to inspect cookie contents when debugging authentication flows, verifying session handling, or auditing what a client sends to the server. Cookie values are often URL-encoded, base64-encoded, or contain JSON payloads that are unreadable in their raw form. When to use it: Debugging a login flow, verifying what a mobile app stores in cookies, auditing session token structure, or checking whether a cookie is base64-encoded JSON before decoding it in your code. What it solves: Parses full Cookie headers or single name=value pairs, URL-decodes percent-encoded values, detects and decodes base64 payloads, and tells you whether the decoded content is valid JSON. Why it matters: Pasting cookies into an online decoder sends your session tokens to a third-party server. This tool runs entirely in your browser — nothing is transmitted, nothing is logged, and the decoded results disappear when you close the tab.

Accepts: full Cookie headers (with or without the Cookie: prefix), semicolon-separated pairs, or a single name=value string.

How Cookie Decoding Works

The decoder first strips any Cookie: prefix from the input, then splits the remaining string on semicolons to isolate individual name=value pairs. Each pair is trimmed, and surrounding double quotes are removed from values that have them.

For each value, the tool checks for percent-encoding. If the value contains valid percent escape sequences, it URL-decodes them. Values that look like base64 — matching the base64url character set and long enough to be meaningful — are decoded and tested for valid JSON content.

Encoding detection reports whether each value was plain text, URL-encoded, base64, or base64-encoded JSON. This tells you at a glance which cookies carry structured payloads and which are opaque session identifiers.

JSON payload extraction surfaces the decoded JSON in a separate panel so you can inspect nested structures like user objects, expiry timestamps, or feature flags without re-decoding manually.

Before / After Examples

Example 1: Base64-encoded JSON Session

❌ Before (Opaque base64 string)

session=eyJ1c2VySWQiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ==

<!-- Cannot inspect without decoding -->

✅ After (Decoded JSON payload)

{
  "userId": "123",
  "role": "admin"
}

<!-- Structure visible at a glance -->

Example 2: URL-encoded Cookie Value

❌ Before (Percent-encoded)

prefs=locale%3Den-US%3Btheme%3Ddark%3Bitems%3D10

<!-- Percent escapes obscure the content -->

✅ After (Readable string)

locale=en-US;theme=dark;items=10

<!-- Values readable directly -->

Example 3: Full Cookie Header from Network Tab

❌ Before (Raw request header)

Cookie: session=abc123; theme=dark; lang=en-US;
csrf=Zm9vYmFy

<!-- Multiple pairs, one unreadable -->

✅ After (Individual decoded pairs)

session  = abc123      (plain)
theme    = dark         (plain)
lang     = en-US        (plain)
csrf     = foobar       (base64 → "foobar")

<!-- Each pair isolated and decoded -->

Use Cases

Developer Production Workflow
Debug session token structure in a local dev environment Inspect what a mobile app stores in cookies Verify cookie encoding before a security audit
Decode base64 JWT payloads stored in cookies Check whether cookies carry PII in plaintext Reproduce a client-side auth bug from a HAR file
Inspect URL-encoded preference cookies Audit third-party tracking cookie payloads Document cookie format for API integration guides
Verify CSRF token encoding scheme Confirm session cookies expire as expected QA regression testing of cookie handling

Common Mistakes & Troubleshooting

Pasting cookies into online decoders

Third-party cookie decoders receive your session tokens on their servers. If the token is a live authentication credential, anyone with access to those logs can impersonate you. Use a client-side tool that never transmits data.

❌ Paste session token into random online decoder
✅ Use a browser-only tool that makes no network calls

Assuming base64 means encrypted

Base64 is an encoding, not encryption. Anyone can decode it. If your application stores sensitive data in base64 cookies, treat that data as public. True protection requires server-side sessions or signed/encrypted tokens.

❌ "It's base64, so it's safe"
✅ Base64 is reversible — never store secrets in cookies

Forgetting to URL-decode before parsing

If a cookie value contains percent-encoded characters, parsing it without decoding first yields incorrect results. This tool auto-decodes, but when writing your own parser, always decodeURIComponent before splitting on delimiters.

❌ Split raw value on "=" without decoding
✅ decodeURIComponent(value) first, then parse

Not checking cookie flags

This tool decodes values, but does not show flags like HttpOnly, Secure, or SameSite. Check those in your browser's Application tab — a cookie with a sensitive value but missing Secure and HttpOnly is exposed to XSS and network interception.

❌ session=secret  (no flags checked)
✅ Verify HttpOnly, Secure, SameSite in browser devtools

Exposing decoded values in screenshots or logs

Decoded cookie payloads often contain user IDs, email addresses, or roles. When sharing debug output with teammates, redact sensitive fields before posting screenshots or pasting logs into chat.

❌ Screenshot full decoded payload in Slack
✅ Redact userId, email, and token fields before sharing

Best Practices

✓

Use client-side tools for sensitive data

Session tokens and auth cookies should only ever be pasted into tools that run entirely in your browser with no network calls.

✓

Treat base64 as public data

Base64 encoding is trivially reversible. Never assume a base64 cookie value is protected. Keep secrets server-side.

✓

Set HttpOnly and Secure flags on auth cookies

HttpOnly prevents JavaScript access, reducing XSS risk. Secure means the cookie is only sent over HTTPS. SameSite adds CSRF protection.

✓

Minimize cookie payload size

Every cookie is sent with every request. Keep cookie values small — store a session ID, not the entire user object.

✓

Rotate session tokens periodically

Even with secure flags, long-lived tokens increase exposure. Rotate them on login and after privilege changes.

✓

Log out by clearing cookies server-side

Deleting the cookie client-side does not invalidate the session. Always invalidate the session server-side on logout.

✓

Audit third-party cookies for PII

Analytics and advertising cookies sometimes store identifiers that qualify as personal data under GDPR. Decode and audit them regularly.

✓

Use consistent encoding across your stack

If your backend URL-encodes cookie values, confirm your frontend decodes them the same way. Mismatched encoding causes subtle parsing bugs.

Frequently Asked Questions

What is a cookie and what does it typically contain? +

A cookie is a small key-value pair that a website stores in your browser and sends back with every subsequent request to that domain. Common cookie contents include session identifiers, authentication tokens, user preferences, locale settings, and tracking identifiers. The value is usually opaque to the user — a random string the server recognizes — but some applications store base64-encoded or JSON payloads directly in the cookie value for client-side convenience.

How do I see the cookies a website set on me? +

Open your browser developer tools, go to the Application tab (Chrome) or Storage tab (Firefox), and expand the Cookies section under your site origin. You will see each cookie with its name, value, domain, path, expiry, and flags. Alternatively, inspect the Set-Cookie headers in the Network tab, or view the Cookie request header on any outgoing request. This tool accepts any of those formats — paste the raw header or a single name=value pair.

Why would a cookie value be base64 encoded? +

Base64 encoding lets applications store structured data like JSON inside a cookie value without worrying about special characters that would break the name=value parsing. A common pattern is encoding a small session object — user ID, role, expiry — as base64 JSON so the client can read it without a server round-trip. This tool detects base64 values, decodes them, and tells you whether the decoded content is valid JSON.

Is it safe to decode cookies in a browser-based tool? +

Yes, as long as the tool runs entirely client-side. This decoder uses only local JavaScript — your cookie values never leave your browser, never hit a network endpoint, and are never logged. That is the main advantage over pasting cookies into an online decoder, which sends your session tokens to a third-party server. Always verify that a tool like this has no network calls in its script before pasting sensitive values.

What is the difference between a session cookie and a persistent cookie? +

A session cookie has no expiry date and is deleted when the browser closes. A persistent cookie includes a Max-Age or Expires attribute and survives until that time passes. From a security perspective, session cookies are generally safer because they do not persist on disk, but persistent cookies are necessary for features like "remember me" and language preferences. Neither is encrypted by default — the value is stored and transmitted in plaintext unless the site uses additional protections.

How do I decode a cookie that is URL-encoded? +

Some applications URL-encode cookie values to safely store special characters like spaces, ampersands, or equals signs. This tool automatically detects percent-encoded values and decodes them. If the decoding fails — which happens when the value contains a stray percent sign that is not part of a valid escape sequence — the tool leaves the value as-is and flags the issue so you can inspect it manually.

Can I use this tool to inspect cookies from an HTTP request? +

Yes. Paste the full Cookie request header, including the Cookie: prefix if present. The tool strips the prefix, splits the header on semicolons, and decodes each name=value pair individually. This is useful when debugging authentication issues or verifying what a client is actually sending to your server.