Which of your cookies actually survive?
Paste a URL. We show every cookie the server sets — domain, lifetime, HttpOnly, Secure, SameSite — and tell you whether any of them can still identify a visitor eight days from now on Safari. Most sites discover the answer is no.
A real request from our server. We read the response headers, not your browser.
Set-Cookie header → not capped · document.cookie → capped at 7 days
Safari caps the expiry of any cookie written by JavaScript at 7 days, and evicts localStorage on the same clock. A cookie set by your server in an HTTP response header is not capped — which is why your login session lasts months and your analytics id does not.
This tool sees the server-set cookies. If the table is empty, every identity on that site is on the 7-day clock.
How to read a cookie
| Attribute | What it controls | For a visitor id |
|---|---|---|
| Who wrote it | Server (Set-Cookie) vs JavaScript (document.cookie) | Server — this is the one that decides durability |
| Domain | Which host the cookie belongs to | Your own domain, first-party |
| Expires / Max-Age | How long the browser keeps it | 1–2 years, and Safari will honour it if server-set |
| HttpOnly | Whether JavaScript can read it | Yes, if your backend owns the identity |
| Secure | HTTPS only | Always yes |
| SameSite | Whether it travels on cross-site requests | Lax — None is for genuine cross-site cases only |
Related: first-party tracking scanner · ITP loss estimator · how to make a cookie that survives Safari
Frequently asked questions
What does this tool show me?
Every cookie the server sets on the response for a URL, with its domain, lifetime, HttpOnly, Secure and SameSite flags — and a verdict on whether it survives Safari's ITP. It also flags whether the page writes cookies or localStorage from JavaScript.
Why can't you show me localStorage contents?
localStorage only exists inside the browser, and only after the page's JavaScript runs. A server-side fetch cannot read it. What we can do — and what actually matters — is detect that the page writes to it, which tells you the identity is on Safari's 7-day eviction clock.
What makes a cookie durable?
Two things together: it must be set by a server in a Set-Cookie response header (not by document.cookie), and it must have a long expiry. Server-set cookies are exempt from the 7-day cap Safari applies to JavaScript-written ones.
Should my tracking cookie be HttpOnly?
If your backend owns the identity, yes — HttpOnly means JavaScript never touches it, which keeps it out of every client-side heuristic. If a snippet also needs to read the id, keep it readable but still server-set; the durability comes from who wrote it, not from the flag.
What SameSite value should I use?
Lax for a visitor id. None requires Secure and is really only for genuine cross-site contexts — and it is exactly the configuration browsers are progressively restricting.
Why do I see fewer cookies here than in devtools?
Because your browser also shows cookies written by JavaScript after the page loaded. Those are the ones Safari caps. The gap between this list and your devtools list is your JavaScript-set surface — and the size of your ITP problem.
One durable cookie is the whole fix.
Flowsk sets a first-party visitor id from your own server — HttpOnly, long-lived, invisible to ITP's client-side heuristics — and ties every ad click, email and purchase to it.
More free tools
Same deal — instant, no signup.