Server-Side Cookie

A server-side cookie, also called a server-set cookie, is written by a web server in an HTTP response rather than by JavaScript on the page. It's still stored in the visitor's browser, but it often lasts longer because limits such as Safari's 7-day script cap don't cover it.

How does it differ from a script-set cookie?

The browser holds both kinds. The difference is which part of the site wrote the cookie, and browsers treat the two differently.

	Script-set cookie	Server-side cookie
Written by	JavaScript on the page	The server, in an HTTP response
Safari's 7-day rule	Covered	Not covered by the script rule, with exceptions below
Brave	7-day cap	6-month maximum
Chrome	Up to 400 days	Up to 400 days
Crosses devices	No	No

The Brave and Chrome figures come from Klaviyo's cookie documentation.

Why do people use them?

• Longer recognition in Safari. A customer who reorders every six weeks can outlast a script-set cookie and still be recognized through a server-set one.
• Restoring other cookies. Klaviyo's First-Party ID, __kle_id, is server-set and restores __kla_id when Safari has removed it, for people with an existing profile.

What are the exceptions?

• Safari and cross-site subdomains. Klaviyo's docs say the 7-day cap applies when a subdomain points to a cross-site host. WebKit covers the related practice of CNAME cloaking.
• Safari and IP mismatches. Safari 16.4 can cap server-set cookies at 7 days when the setting server's IP doesn't match the site's first half, according to an Aimerce write-up. Elevar's docs carry a similar caveat.
• One browser only. A shopper who starts on a laptop and opens your email on a phone has no cookie on the phone. See cross-device cart abandonment.
• Consent still applies. How the cookie was written doesn't change your obligations under your store's banner.
• Identity must exist first. Klaviyo's First-Party ID identifies only people with an existing profile, so it won't name a stranger.

How do you recognize customers when cookies go away?

Think of a cookie as one route to recognition. A browser can lose it at any time, and a customer may be on a new device anyway. Practical recognition combines a few things: an identifier that survives on the browser where possible, a moment where the person identifies themselves such as an email click or login, and a record of who they are that lives outside the browser. Returning customer recognition covers the idea, and our longer piece on server-side cookies goes further.

If you run Klaviyo, turn on Extended ID first, since it's on all plans, as explained in Extended ID vs First-Party ID.

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. Strangers aren't identified, and there's no shared identity network. On a returning customer's cart page, that recognition lets the page restore a held cart when reOtter knows who clicked.

Key takeaways

• A server-side cookie is written in an HTTP response and stored in the browser, and it often outlasts a script-set cookie.
• Safari can still cap it at 7 days in some setups, and Brave limits it to 6 months.
• It helps recognition on the same device over time, and it can't carry anyone or any cart to a second device.

See how reOtter restores the cart → Abandoned cart recovery