| Name | Value | Action |
|---|---|---|
| Paste content above to see parsed results | ||
Netscape cookie files can be used with curl -b; if Domain is missing, a placeholder domain is used. Replace it before import.
One page for understanding both Cookie request headers and Set-Cookie response headers during login, API, and browser debugging.
A cookie parser turns cookie text taken from browsers, frontend code, API tools, or server responses into structured results. It does not try to explain cookie theory in the abstract. Instead, it focuses on the questions that come up in real debugging: which cookies were actually sent with the current request, which attributes appear in the Set-Cookie response header, why SameSite / Secure / HttpOnly looks correct but the browser still refuses the cookie, whether the cookie value was URL-encoded, and how to reuse the parsed result in scripts or command-line tools.
A common mistake in lightweight tools is treating document.cookie, the Cookie request header, and the Set-Cookie response header as if they were the same input shape. They are not. document.cookie and request cookies are best viewed as flat name=value pairs, where the main task is checking whether the request carried the right cookies. Set-Cookie is a server-to-browser response header, and the key task there is checking whether SameSite, Path, Domain, Expires, Max-Age, HttpOnly, and Secure were configured correctly.
This page works as a general entry point when you are not yet sure which kind of cookie text you have, or when you are investigating a full login-state problem and need to compare both what the request sent and what the server returned. You can switch between Cookie-string mode and Set-Cookie mode on one page and quickly parse, inspect, filter, copy, and export the result.
Compared with simple online tools that only do split(;), this parser is designed around real debugging readability and reuse. It preserves the raw value while safely showing a decoded value, exposes attribute tables, exports JSON and Netscape Cookie File output, and keeps duplicate cookies visible instead of auto-cleaning away the very signal you may need to diagnose the issue.
If you later need a more focused request-header workflow, use the dedicated HTTP Cookie Parser. If you need to understand why the browser rejected a cookie, whether SameSite=None is missing Secure, or whether Set-Cookie security attributes are invalid, switch to the specialized Set-Cookie Parser. This page is best understood as the main cookie debugging hub and routing page.
This page works well as the main cookie debugging entry point, but if you already know what kind of data you have, a specialized tool will be faster.
| Tool | Best input | Best for | Core strength |
|---|---|---|---|
| Cookie Parser (this page) | Cookie strings, document.cookie, multi-line Set-Cookie | When you are not sure about the input type or want to handle request and response cookies in one place | Dual-mode switching, JSON / Netscape export, and a practical main cookie debugging hub |
| HTTP Cookie Parser | Cookie request headers and document.cookie-style strings | Checking which cookies the request actually carried, whether names are duplicated, and whether values were URL-encoded | More focused on request-side name/value parsing for sessions and login-state debuggingOpen HTTP Cookie Parser |
| Set-Cookie Parser | Set-Cookie response headers returned by the server | Checking why the browser refused a cookie and whether SameSite / Secure / HttpOnly settings are risky | Deeper attribute inspection for security settings and browser-policy issuesOpen Set-Cookie Parser |
If the text came from frontend code, document.cookie, request logs, or a curl header, start with Cookie-string mode. If it came from Response Headers in the browser Network panel, switch to Set-Cookie mode instead, or you will misread attributes as plain key-value data.
HTTP Cookie ParserSet-Cookie ParserMany cookie values are URL-encoded. During debugging you should keep both the raw value and the decoded value visible, especially when you are checking signatures, Base64, JWT, or double-encoding done by the server.
Duplicate cookies usually mean different paths, different domains, or leftover writes from earlier flows. Auto-deduplication can hide the real root cause. It is safer to keep duplicates visible and compare them against the request path, scope, and Set-Cookie configuration.
If you only want to paste the result into docs, an issue, or a script, JSON is usually clearer. If you want to feed the result into curl, a crawler, or a tool that imports cookie files, choose Netscape Cookie File instead.
curl to codeIt supports two main input types: flat name=value; name2=value2 strings such as document.cookie or a Cookie: request header, and multi-line Set-Cookie response headers copied from the browser Network panel. The first is best for seeing which cookies were actually sent in a request, while the second is better for checking SameSite, Secure, HttpOnly, Path, Domain, Expires, and Max-Age settings.
A Cookie request header is the flat key-value list the browser sends to the server, without attribute metadata. Set-Cookie is the response header the server sends back to the browser. Each line describes one complete cookie configuration and can include Path, Domain, Expires, SameSite, Secure, HttpOnly, and other attributes in addition to the name and value. Use Cookie parsing to debug what the request carried, and Set-Cookie parsing to debug why the browser accepted or rejected a cookie.
Many cookie values are URL-encoded. For example, %3D means = and %2F means /. The tool keeps the raw value and also shows the URL-decoded version so you can confirm the real content without losing the original input.
Duplicate names can come from different Paths, different Domains, or repeated writes during debugging. The duplicate itself is often an important clue, so the tool warns you about it instead of deduplicating automatically and hiding the real issue.
JSON export is better when you want to keep working with scripts, test cases, API docs, or log analysis. Netscape Cookie File export is better when you want to reuse cookies in tools or command-line flows that support that format, such as curl -b. JSON is more structured, while Netscape format is better for compatibility with older cookie workflows.
Yes. You can first inspect which cookies the request actually carried in Cookie mode, then switch to Set-Cookie mode to check whether the server-side attributes are wrong, such as SameSite=None without Secure, a mismatched Path, an invalid Max-Age, or the wrong Domain scope.
The combined parser is useful when your debugging session may involve either document.cookie or Set-Cookie and you want one entry point. If you already know you only need request cookies, the dedicated HTTP Cookie Parser is more focused. If you only need response headers, the Set-Cookie Parser goes deeper on attribute validation and security checks.
No. Cookie parsing, URL decoding, JSON preview, and Netscape text generation all run locally in your browser. Nothing you paste is uploaded, which makes the page suitable for sensitive cookies copied from test, staging, or even production troubleshooting flows.
Yes. The tool parses each Set-Cookie line and shows structured fields such as SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, and Partitioned so you do not need to count semicolons by hand in the raw header.
Yes. In request-header mode you can copy normalized Cookie content. The combined parser also exports JSON and Netscape Cookie File text so you can continue using the result in curl, crawler scripts, API testing tools, or automation tasks.
Many cookie debugging problems come from misidentifying the input shape before you even start parsing.
| Input type | Typical example | Contains | Better tool |
|---|---|---|---|
| document.cookie / Cookie request header | session=abc; theme=dark; lang=zh-CN | Only flat name=value pairs, without attributes | Cookie-string mode on this page, or the HTTP Cookie Parser |
| Set-Cookie response header | session=abc; Path=/; HttpOnly; Secure; SameSite=Lax | name=value plus security and lifetime attributes | Set-Cookie mode on this page, or the Set-Cookie Parser |
| Netscape Cookie File | .example.com TRUE / FALSE 0 sid abc123 | Domain, path, secure flag, expiry time, name, and value | This page can generate it for reuse in curl and scripts |
When you troubleshoot cookies, first separate request-side missing cookies from browser-side rejection.
| Symptom | Likely cause | Check first |
|---|---|---|
| The target cookie is completely missing from the request | The cookie was never written successfully, or Path / Domain scope does not match | Inspect Set-Cookie mode first, then inspect request-header mode |
| Cross-site requests do not send cookies | SameSite restrictions, missing Secure, or browser third-party cookie policy | Check first whether SameSite=None is paired with Secure |
| The cookie value looks garbled | The value was URL-encoded, or wrapped again in Base64 / JWT by the server | Open the decoded view, then continue with JWT / Base64 if needed |
| Cookies with the same name behave inconsistently | Multiple writes exist under different Paths or Domains | Keep duplicates visible and compare scope plus write origin |
| curl or scripts cannot directly reuse browser cookies | You are missing a standardized export format | Switch to JSON export or Netscape Cookie File export |
Cookie parsing, URL decoding, JSON preview, and Netscape text generation all happen locally in your browser. Session, Token, login cookies, and copied response headers are not uploaded to any server.
