Set-Cookie Parser

About GeekFormat

Set-Cookie Parser

Paste multi-line Set-Cookie response headers to inspect attributes and flag risky SameSite / Secure combinations.

Cookie Attribute Cards

2 Set-Cookie(s)

#1sessionabc123

path/

httponly(flag)

secure(flag)

samesiteLax

No obvious attribute issues found

#2preview1

max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone

secure(flag)

setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

JSON Preview

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

When browsers reject cookies, the value is rarely the problem—it's usually the Set-Cookie attributes.

HTTP Cookie Parser

Cookie Parser

Security Headers Checker

CORS Inspector

Authentication Header Generator

cURL to Code Generator

What is a Set-Cookie Parser?

A Set-Cookie parser is a debugging tool specifically designed for the `Set-Cookie` content in HTTP response headers. Its goal isn't simply to split a line of text by semicolons, but to help developers determine: whether the server's cookie configuration is correct, why the browser didn't accept it, which attribute combinations pose security or compatibility risks, and whether the current Set-Cookie is suitable for cross-site, SSO, iframe, third-party cookie or session scenarios.

Unlike the Cookie in request headers, Set-Cookie is the server's "configuration instruction sent to the browser." It contains not just `name=value` but also attributes like SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age and Partitioned. These fields directly determine whether the browser stores the cookie, when it expires, which paths and domains it applies to, and whether it can be sent in cross-site requests. Therefore, the root cause of many "lost session" issues—browsers not sending cookies, cross-origin scenarios not working—often lies not in the value itself but in Set-Cookie attribute configuration.

The value of this page is in structurally extracting these attributes from raw response headers and then performing static checks against real browser rules. For example: does SameSite=None lack Secure, is Partitioned paired with Secure, does the __Host- prefix incorrectly set a Domain, is Max-Age invalid or zero, is Expires missing a matching Max-Age? Browsers usually don't show explicit errors for these problems like they do for syntax errors; instead they silently reject or simply "don't work," making tool-assisted checking essential.

If you only want to know which cookies are currently being sent in a request, don't stay on this page—use the HTTP Cookie Parser instead, which is better suited for request header dissection. This page is designed for response header troubleshooting: "why didn't the browser store it," "does this server cookie configuration have hidden risks," and "is the cross-site and security attribute combination correct."

Use Cases

When browsers reject cookies, quickly identify whether the issue is SameSite, Secure, HttpOnly, or Path/Domain configuration
In third-party login, SSO, iframe embedding or cross-site request scenarios, verify that SameSite=None is correctly paired with Secure
During security audits, batch-check whether API-returned cookies are missing HttpOnly, missing SameSite, or contain high-risk attribute combinations
Verify that __Host- / __Secure- prefix cookies satisfy browser strict constraints to avoid silent rejection
When debugging Partitioned Cookie / CHIPS third-party partitioned schemes, confirm that Partitioned and Secure are both declared
Compare Set-Cookie response header differences across development, testing and production environments to troubleshoot session anomalies after environment switches

How to Use

Copy Set-Cookie response header content from browser DevTools, packet capture tools or server logs (multi-line supported)
Paste into the input area; the tool automatically strips the `Set-Cookie:` prefix and parses line by line
View each cookie's name, value, URL-decoded value, attribute cards and warning labels
Copy raw headers or view JSON preview to send results to backend developers, paste into issues, or write into test scripts

Features

Independent multi-cookie parsing: Each Set-Cookie line becomes its own card showing name, raw value, URL-decoded value and attributes
14 common issue auto-checks: Covers high-frequency risks around SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, __Host-/__Secure- prefixes and Partitioned
Complete attribute breakdown: Structured display of SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned and other fields
Human-readable Max-Age conversion: Seconds automatically converted to minutes, hours and days, eliminating manual calculation
Multi-line batch input: Paste entire Set-Cookie response headers copied directly from DevTools or packet capture tools
Raw header copy & JSON preview: Convenient for sending back to backend developers and for writing docs, issues, scripts and test cases
Local processing with zero upload: Sensitive sessions, tokens and login cookies parsed entirely in the browser without leaving your device

When to use Set-Cookie Parser vs. the other two pages?

Seeing "what the server set" and "what's actually in the request" are two different things—don't confuse them.

Tool	Best Input	Best For	Core Strength
Set-Cookie Parser (this page)	Set-Cookie response headers	Debugging why browsers reject cookies, why cross-site doesn't work, why security attributes pose risks	Complete attribute breakdown with automatic checks for 14 high-frequency configuration issues
HTTP Cookie Parser	Cookie request header, document.cookie	Confirming which cookies are actually sent in requests, whether values are URL-encoded, whether duplicate names exist	Focused on request header name-value pair dissection and standardized outputOpen HTTP Cookie Parser
Cookie Parser	Mixed Cookie strings and Set-Cookie debugging scenarios	When you're unsure of your data source or want to quickly switch between Cookie / Set-Cookie modes on one page	Acts as a general cookie debugging entry point and supports Netscape Cookie File exportOpen Cookie Parser

Best Practices

First determine if the problem is "set failed" or "not sent in request"

If the browser never stored the cookie at all, start with this page. If the browser stored it but subsequent requests don't include it, use the HTTP Cookie Parser alongside. Set-Cookie and Cookie request headers are two different phases.

For cross-site scenarios, first check the SameSite=None and Secure combination

The most common pitfall in SSO, third-party login, iframe embedding and cross-origin requests is SameSite=None without Secure. Eliminate this issue first before investigating server logic and browser policies.

Don't judge Host- / Secure- prefixes by name alone—verify all constraints are met

Many teams assume that adding `__Host-` or `__Secure-` to a cookie name makes it more secure, but if supporting conditions like Secure, Path=/ and Domain aren't satisfied, browsers will still reject it.

When documenting or reproducing issues, preserve both raw headers and JSON output

Raw headers help backend and ops verify actual responses; JSON is suitable for pasting into issues, test cases and scripts. Keeping both is better than just a DevTools screenshot for reproduction and collaboration.

FAQ

What's the difference between Set-Cookie parser and Cookie request header parser?

The Set-Cookie parser focuses on server response headers, examining whether the browser will accept the cookie and whether attributes have issues. The Cookie request header parser focuses on outgoing browser requests, showing exactly which cookies are being sent. If you're troubleshooting SameSite, HttpOnly, Secure, Path, Domain, Expires, or Max-Age configuration issues, use this page first.

HTTP Cookie Parser

Why does the browser receive the response but not set the cookie?

This is exactly the problem this tool is designed to solve. Common causes include SameSite=None without Secure, Secure cookies set on HTTP pages, __Host- prefix violations, Partitioned without Secure, unreasonable Path or Domain configuration, invalid or zero Max-Age, and browser third-party cookie policy restrictions.

What common Set-Cookie risks does the tool check?

This page automatically detects 14 high-frequency issues: SameSite=None without Secure, invalid SameSite value, Partitioned without Secure, missing HttpOnly, missing Path, missing SameSite, __Host- prefix missing Secure / Path not / / mismatched Domain, __Secure- prefix missing Secure, invalid Max-Age, Max-Age=0, Domain starting with a dot, and Expires without Max-Age.

Why must SameSite=None be paired with Secure?

Modern browsers require that cookies available for cross-site sending with `SameSite=None` must also include the `Secure` attribute; otherwise browsers typically reject them outright. This issue is extremely common in third-party login, SSO, iframe embedding and cross-origin request debugging.

Why are Host- and Secure- prefix cookies rejected by browsers?

`__Host-` and `__Secure-` are security prefixes with strict constraints. `__Host-` requires Secure, Path=/ and no Domain attribute; `__Secure-` requires at minimum the Secure attribute. If these rules are violated, browsers silently ignore the cookie.

How should I interpret Max-Age and Expires?

Max-Age is a relative duration in seconds and typically takes precedence over Expires; Expires is an absolute point in time that depends on the client clock. Many servers set only Expires without Max-Age, which works but is more error-prone during debugging due to timezone or system clock skew.

Is this tool suitable for debugging cross-site and third-party cookie issues?

Yes. Whether it's third-party login, SSO, embedded iframes, cross-origin APIs or CHIPS (Partitioned Cookie) scenarios, this tool helps you quickly verify whether the combination of SameSite, Secure and Partitioned is correct.

Can I copy or export the parsed results?

Yes. You can copy the raw Set-Cookie header with one click or view the structured JSON preview, then paste each cookie's name, value, attributes and warning results into issues, documentation, test scripts or debugging notes.

Will my copied sessions and tokens be uploaded to a server?

No. Set-Cookie parsing, URL decoding, attribute extraction and warning checks all run locally in your browser. Sensitive response headers are never uploaded to any server.

Glossary

Set-Cookie: An HTTP response header through which the server tells the browser to store a cookie. A single response can contain multiple Set-Cookie headers, each typically corresponding to one cookie.
SameSite: An attribute controlling whether cookies are sent in cross-site requests. Common values are Strict, Lax and None; None generally requires Secure to also be set.
HttpOnly: When set, frontend JavaScript cannot read the cookie via document.cookie, primarily used to reduce the risk of session theft via XSS.
Secure: When set, browsers only send the cookie over HTTPS connections (or localhost exceptions), preventing sensitive cookies from being exposed over plaintext HTTP.
Max-Age: The relative lifetime of a cookie in seconds. Typically takes precedence over Expires; recommended to set explicitly on the server.
Expires: The absolute expiration time of a cookie, dependent on the client's local clock. When used alone, debugging is generally more difficult than with Max-Age.
Path: Restricts the URL path prefix where the cookie is effective. If Path doesn't match, subsequent requests won't include the cookie even if stored.
Domain: Restricts the domain scope where the cookie is effective. When unset it typically applies only to the current host; when set it may apply to subdomains.
Partitioned (CHIPS): A third-party cookie partitioned storage scheme, commonly used as an alternative path as browsers progressively restrict third-party cookies. Current implementations typically require pairing with Secure.
__Host- / __Secure- prefixes: High-security cookie naming prefixes supported by browsers, carrying strict constraint rules. When rules are violated, browsers reject the corresponding cookie.

SameSite Three-Strategy Quick Reference

When debugging cross-site cookies, first understand SameSite behavior boundaries, then check whether Secure is missing.

SameSite Value	Cross-site Top Navigation (GET)	Cross-site Subresource (img/iframe/script)	Cross-site POST Form	Cross-site XHR/fetch	Secure Required
Strict	Not sent	Not sent	Not sent	Not sent	No
Lax (default)	Sent	Not sent	Not sent	Not sent	No
None	Sent	Sent	Sent	Sent	Secure required

Set-Cookie Debugging High-Frequency Issues Reference

When browsers silently reject cookies, checking in these directions is usually faster than staring at the response body.

Symptom	Likely Cause	Check First
Browser completely fails to store cookie	SameSite=None without Secure, prefix violation, or invalid attribute combination	Start with the warning labels and attribute cards on this page
Doesn't work in cross-site / iframe scenarios	SameSite too restrictive, missing Secure, or third-party policy restrictions	Focus on SameSite, Secure, Partitioned
Cookie expires immediately after being set	Max-Age=0, invalid Max-Age, or Expires time issues	Check Max-Age first, then Expires
__Host- / __Secure- cookie not working	Secure, Path=/ or Domain constraints not satisfied	Verify whether prefix warnings are triggered
Works in development but not production	HTTPS, Domain, Path, SameSite or proxy-layer response differences	Copy raw headers and compare Set-Cookie responses across environments

Privacy & Security

Set-Cookie response header parsing, URL decoding, attribute extraction and all 14 warning checks run entirely locally in the browser. Pasted sessions, tokens and login cookies are never uploaded to any server.

Set-Cookie Parser