Set-Cookie Inspector

Paste one header per line or build a new value. The tool works on text; it neither reads nor writes your browser’s cookies.

Runs locally in your browser
This tool processes all data locally in your browser.
Set-Cookie headersPaste one Set-Cookie response header per line.
Build a Set-Cookie headerThis creates text only; it never writes a browser cookie.

How to inspect Set-Cookie headers and build a safe cookie

Paste one Set-Cookie response header per line. Each line is split into its name, value and attributes, and the checks below say what a browser will reject or quietly ignore: SameSite=None without Secure, a __Host- prefix that carries a Domain, a Path that does not start with /, a Max-Age that is not a number, a Partitioned cookie without Secure.

The page is a text tool. It does not read or write the cookies stored in your browser, it makes no network request while it works, and nothing you paste is uploaded.

  1. Paste the Set-Cookie headers you copied from a response, one per line, or press Load example to start from a known pair.
  2. Press Inspect headers. Every line becomes a card with its attributes, and the check list names what blocks the cookie and what the browser will ignore.
  3. Fix the header in your server configuration, then paste the new value and inspect it again.
  4. To write a cookie from scratch, fill in name, value, domain, path, Max-Age and SameSite, tick Secure, HttpOnly or Partitioned, and press Build Set-Cookie.
  5. Press Copy or Download to take the generated header into your server configuration.

What the checks cover

What makes a browser drop a cookie

A cookie is dropped completely, not partially, when its name uses characters outside the RFC 6265 token set, when SameSite=None is sent without Secure, when a __Host- name also carries Domain, when a __Host- cookie has a Path other than / or no Secure, or when Partitioned appears without Secure.

Other attributes are skipped one by one: a Path that does not start with /, an Expires that is not a valid date and a Max-Age that is not an integer are all ignored while the cookie itself still arrives.

What the builder refuses to generate

The builder is deliberately strict. It stops instead of printing a header a browser would throw away: a semicolon or control character in the value, a __Host- name with a Domain, __Secure- or Partitioned without Secure, SameSite=None without Secure, or a Max-Age that is not a whole number of seconds.

The output is plain text for your server configuration; check it against the response headers your server really sends.

Session cookies, deletion and Domain scope

No Max-Age and no Expires means a session cookie, which the browser drops at the end of the session. Max-Age=0 or a date in the past deletes a cookie that already exists.

A leading dot in Domain is ignored by modern browsers: .example.com and example.com now share the same scope. A Domain of a single label, such as .com, is accepted only when the page host carries exactly that name.

Recent tools: