How to Use a Cookie Decoder Tool to Parse HTTP Cookies
A cookie decoder tool turns a raw Cookie or Set-Cookie string into fields you can actually read. That matters when you are debugging a login loop, checking whether SameSite=None is paired with Secure, or trying to tell whether a cookie value is plain text, Base64, URL-encoded data, or a token format such as JWT. A good decoder saves time because it separates the name, value, domain, path, expiry, and security flags in one view instead of making you read one long header string by eye. OnSumo's Cookie Decoder runs in the browser, so the string you paste stays on your device. If the value inside the cookie turns out to be encoded JSON or a token, you can keep moving with the Base64 Encoder / Decoder, URL Encoder / Decoder, JSON Validator & Formatter, or JWT Decoder.
What a Cookie Decoder Tool Does
A cookie decoder tool parses cookie syntax. It does not break encryption. That distinction is the main thing people miss. If you paste this header: ``http Set-Cookie: session=eyJ1aWQiOjEyMywicm9sZSI6Im1lbWJlciJ9; Path=/; HttpOnly; Secure; SameSite=Lax ` A parser can split the cookie into: - Name: session - Value: eyJ1aWQiOjEyMywicm9sZSI6Im1lbWJlciJ9 - Path: / - HttpOnly: true - Secure: true - SameSite: Lax` That is structural decoding. If you want to inspect the value itself, you may need one more step. In this example the value is Base64 text, so you would copy it into the Base64 Encoder / Decoder and get readable JSON back. If the value is encrypted, no public decoder can turn it into useful text without the server-side key.
How to Read the Main Cookie Fields
The main fields tell you whether a cookie should be sent, when it expires, and what code can access it. - Name: The cookie identifier, such as session_id, _ga, or csrftoken. - Value: The payload. It may be plain text, an opaque session ID, Base64 text, URL-encoded text, JSON, or a token. - Domain: The host scope. A cookie with Domain=.example.com can be sent to subdomains under example.com. - Path: The URL path scope. A cookie with Path=/admin is not sent to unrelated paths. - Expires / Max-Age: The lifetime. MDN and the current HTTP cookie draft both note that Max-Age takes precedence when both are set. - Secure: The browser only sends the cookie over HTTPS. - HttpOnly: JavaScript cannot read the cookie with document.cookie. - SameSite: The cross-site sending policy. Strict, Lax, and None each change when the browser attaches the cookie. Those fields answer different debugging questions. If a cookie is missing on a request, check Domain, Path, SameSite, and Secure. If front-end code cannot read it, check HttpOnly. If a user is being logged out too early, check Expires or Max-Age.
How to Get a Cookie String to Decode
The fastest way to get cookie data is from your browser's developer tools. In Chrome 1. Open DevTools. 2. Go to Application and open Cookies to inspect stored cookies. 3. Go to Network if you want to see the raw Set-Cookie response header. 4. Copy the cookie row or header value into the Cookie Decoder. Chrome DevTools also lets you view a cookie's value in decoded form, which is useful when percent-encoding hides readable characters. In Firefox 1. Open DevTools. 2. Go to Storage and open Cookies. 3. Copy the value you want to inspect. 4. Paste it into the decoder. If the cookie came from a response header, the HTTP Header Analyzer is also useful because it lets you inspect Set-Cookie next to the rest of the response headers that can affect security and caching.
How to Tell Whether the Value Is Plain Text, Base64, URL-Encoded, or JWT
The easiest first pass is to look at the character pattern. - Plain text often looks readable right away: theme=dark or region=us. - URL-encoded text contains % escapes such as %3D, %2F, or %20. Send those values to the URL Encoder / Decoder. - Base64 often uses letters, numbers, /, +, and optional = padding at the end. Send those values to the Base64 Encoder / Decoder. - JWTs have three dot-separated segments such as header.payload.signature. Send those to the JWT Decoder. - JSON values may start with curly braces after decoding. Use the JSON Validator & Formatter to clean them up. If none of those patterns fit, you are probably looking at an opaque identifier or encrypted value. In that case, a cookie parser still helps because it confirms the value format and the surrounding attributes, even if the payload itself stays unreadable.
Worked Example: Debugging a Cookie That Will Not Stick
Cookie parsing is most useful when a cookie is present in a response but missing on the next request. Start with this response header: ``http Set-Cookie: auth_token=abc123; Path=/; SameSite=None ` A cookie decoder shows two important things fast: 1. The cookie has SameSite=None. 2. The cookie does not have Secure. Current browser guidance is clear on this point: cookies marked SameSite=None must also use Secure. Without it, modern browsers can reject the cookie in cross-site contexts. That means the app may look like it "set" the cookie even though the browser never keeps it in a usable way. Now compare it with: `http Set-Cookie: auth_token=abc123; Path=/; SameSite=None; Secure; HttpOnly ` The second header is much more likely to behave as expected for a cross-site authentication flow. If the value is still not available where you expect it, the next checks are Domain, Path, and whether your JavaScript code is trying to read a cookie that is deliberately protected by HttpOnly`.
Cookie Decoder vs. Browser DevTools
Browser DevTools is still the source of truth for what the browser stored. A cookie decoder is faster when you need a clean field-by-field view, a copied record for documentation, or a quick pass on pasted Set-Cookie headers from logs, bug reports, or support threads. Use DevTools when: - you need to see whether the browser actually stored the cookie - you want to inspect multiple cookies for one domain - you need request-by-request context in the Network panel Use a cookie decoder when: - you have one raw cookie string and need it parsed fast - you are reading a support ticket or error log outside the browser - you need to hand the decoded structure to someone else - you want to move the value into a Base64, URL, JSON, or JWT tool next
Frequently Asked Questions
What is a cookie decoder tool?
A cookie decoder tool parses a raw cookie string into readable fields such as name, value, domain, path, expiry, Secure, HttpOnly, and SameSite.
Does a cookie decoder decrypt secure session cookies?
No. It can parse the cookie structure and sometimes decode plain encodings such as Base64 or URL encoding, but encrypted values still need the server-side key.
Is my cookie data sent to a server?
No. OnSumo's Cookie Decoder runs entirely in the browser. Cookie strings you paste are processed locally by JavaScript on your device and are never uploaded to OnSumo servers.
What does HttpOnly mean?
HttpOnly means browser JavaScript cannot read the cookie with document.cookie. The browser can still send it in HTTP requests.
What is the difference between Expires and Max-Age?
Both control the cookie lifetime. Expires uses a fixed date and time. Max-Age uses a number of seconds. When both appear, Max-Age takes precedence.
Why does my cookie value look like gibberish?
It is often encoded, compressed, signed, or encrypted. Base64 and URL-encoded values can be decoded with companion tools. Encrypted values cannot be read without the key used by the application.
How do I view cookie details in Chrome?
Open DevTools, then check Application, then Cookies for stored cookies or Network for raw Set-Cookie headers. Chrome's docs also note you can show URL-decoded cookie values in DevTools.