Cart Recovery
The Safari 7-Day Cookie Limit, Explained for Klaviyo Brands
Safari can delete JavaScript-set cookies after 7 days of browser use without interaction with your site. Here's how that affects Klaviyo's tracking cookie, what Extended ID and First-Party ID change, and the one thing no cookie setting can fix.
Sam Schrup · October 31, 2026
Safari can delete cookies set by JavaScript after 7 days of browser use without interaction with your site. For Klaviyo brands, that means a known shopper can quietly turn anonymous in Safari, and flows that depend on Klaviyo recognizing the browser may not fire for that person.
This limit comes up constantly in vendor pitches, often in a simplified form. Here's what's documented, what Klaviyo offers against it, and what it has no bearing on.
What exactly does Safari limit?
WebKit's tracking prevention policy places a 7-day cap on script-writable storage. Safari's tracking protection as a whole is known as Intelligent Tracking Prevention, or ITP. Cookies set through an HTTP response aren't covered by the JavaScript rule.
Klaviyo's cookie documentation adds a shorter case. Expiry can drop to 24 hours after navigation from a known tracker to a URL with query parameters or fragments.
How does this affect Klaviyo's tracking?
Klaviyo's __kla_id is the cookie that ties a browser to a profile. It's set by JavaScript, with a two-year lifetime that browsers can shorten. In Safari, it's deleted after 7 days of browser use without interaction with your site.
Picture a repeat customer on an iPhone. They bought five weeks ago and they use Safari every day. By the time they come back, the cookie may be gone. If they add something to their cart, Klaviyo may not know who they are. So the Added to Cart event may not reach their profile, and the flow can't send.
That's a real gap, and it's only part of the picture. It doesn't apply to everyone, because a shopper who visited within the window keeps the cookie, and an email click or a form can identify someone again. Klaviyo misses some shoppers because of this, and we'd be cautious of anyone quoting a single percentage for your store without measuring it.
What can Klaviyo do about it?
Klaviyo has two relevant features, and you may not have looked at them recently.
| Extended ID | First-Party ID | |
|---|---|---|
| What it is | Klaviyo's option for extending identification | A server-set cookie, __kle_id |
| What it does | Helps Klaviyo keep recognizing a browser for longer | Restores __kla_id after it's lost |
| Availability | All Klaviyo plans, free and paid | Check your plan and setup in Klaviyo |
| Who it can identify | People Klaviyo has already identified | Only people with an existing profile |
Start with Extended ID, since it's available on every plan. Our answer on Extended ID vs First-Party ID walks through the choice.
The First-Party ID has a caveat worth knowing. Klaviyo's docs say Safari's 7-day cap applies to its server-set cookie when a subdomain points to a cross-site host.
Do server-set cookies get around the limit?
Often, with exceptions. A server-side cookie reaches the browser in an HTTP response, so the JavaScript rule doesn't cover it. Safari has narrower rules that do:
| Safari behavior | What it affects | Source |
|---|---|---|
| 7-day cap on script-writable storage | Cookies set by JavaScript | WebKit |
| CNAME cloaking defense | Cookies from a subdomain pointing at a third-party host | WebKit |
| IP address matching | Server-set cookies capped at 7 days when the setting server's IP doesn't match the first half of the site's IP (Safari 16.4) | Aimerce write-up, with a similar caveat in Elevar's docs |
So a cookie being server-set isn't enough on its own. The hosting behind it matters. If a vendor sells you durable Safari cookies, ask three questions:
- Which server sets the cookie, and does its IP match the first half of ours?
- Does the setup use a subdomain that points to a cross-site host?
- What lifetime do you actually observe in current Safari, and how did you measure it?
For a fuller look at the advantages and exceptions, see our post on server-side cookies and returning customers.
What can't any cookie fix?
Other devices. A cookie stays on one browser on one device, so the laptop's cookie is no help to the phone. This is the point that gets lost when Safari is treated as the cause of every cart recovery problem.
Follow a shopper who builds a cart in Chrome on a laptop. Their cookie is in fine shape. Klaviyo knows them, so the flow fires and the email arrives. They open it on a phone and tap the button. They reach an empty cart or a product page and rebuild from memory. Safari limits played no part, and a longer-lived cookie would change nothing.
That's cross-device cart abandonment, and the fix comes from a different direction. It takes a cart saved on a server and something that tells you who clicked, such as the email click or a store login.
Keeping the problems apart helps you spend in the right place:
| Symptom | Likely cause | Where to look |
|---|---|---|
| Known customers aren't entering the flow | Lost cookie, on Safari especially | Extended ID, First-Party ID, an event relay |
| The flow fires, and clicks land on an empty cart | Cross-device click | Where the click goes |
| Returning customers look like new visitors on site | No recognition on the page | Returning customer recognition |
How can you check your own exposure?
You don't need a vendor to start. Three checks will tell you a lot.
- Look at the Safari share of your traffic and orders. Your analytics can show this. The larger the share, the more this limit matters to your store.
- Run a manual test. On an iPhone, click a Klaviyo email from your store, then add to cart. Confirm the event on your profile. Come back after Safari's window has passed and try again.
- Run a second-device test. It tests the separate cross-device problem, and it's quick.
Where does reOtter fit?
reOtter recognizes people who've already given your brand their details, without a third-party network, in a record that doesn't depend on a browser cookie surviving. It doesn't identify strangers.
We aren't claiming that this finds more abandoners than your current setup. The reOtter cart recovery page handles what happens after someone has clicked your Klaviyo email. When reOtter holds that shopper's cart and knows who clicked, the cart goes back on whatever device they're on. Carts are held only with analytics consent, for 30 days, and if the cart isn't held or the clicker isn't known, the shopper sees the page with whatever cart that device has.
You can see how that works on our abandoned cart recovery page. And turn on Klaviyo's Extended ID today whatever you decide about us.
Frequently asked questions
- Does Safari delete all cookies after 7 days?
- No. The 7-day cap applies to script-writable storage, including cookies set by JavaScript. Cookies set in an HTTP response aren't covered by that rule, though Safari has other limits that can cap some of them at 7 days too.
- Does the 7-day clock run on calendar days?
- Klaviyo's documentation describes it as 7 days of browser use without interaction with the site. A visit with interaction resets the clock. Someone who uses Safari daily and doesn't come back to your store will reach the limit quickly.
- Will fixing Safari cookies fix my cross-device cart problem?
- No. Cookies stay on one browser on one device. A shopper who builds a cart on a laptop and clicks on a phone needs a saved cart and an identified click, whatever the laptop's cookie settings.