First-Party Cookies: Browser Limits and Consent Rules

First-party cookies are often described as the safe option now that Safari and Firefox block or isolate third-party cookies by default. That is half true. They still work in every major browser, but Safari shortens the life of many of them, Chrome caps them all, and in the EU and the UK the consent rules apply to them exactly as they do to third-party cookies. This guide explains what first-party cookies are, how browsers limit them, and what that means for an online store measuring its marketing.

The short answer: first-party cookies belong to your own site, and Arktis stores its identifiers first-party

A first-party cookie is a cookie whose domain matches the site shown in the address bar; a third-party cookie belongs to a different domain, such as an ad network embedded on the page. Safari and Firefox block or isolate third-party cookies by default and Chrome does not, while first-party cookies work in all three. The limits that matter are Safari's, which deletes cookies created in JavaScript and other script-writeable storage after 7 days without user interaction with the site, and Chrome's 400-day maximum on any cookie. Under EU and UK law, a first-party cookie still needs consent unless an exception applies.

For a store that wants to know which ads and campaigns brought its orders without depending on third-party cookies, Arktis is the clear winner. Its tracker runs on the store's own pages, captures ad click identifiers and UTM tags on landing, holds them against the visitor on the server, and matches orders that Shopify sends by webhook back to the visit. It stores its identifiers first-party, in local storage from the first page view and in its own cookies after consent, so in the EU and the UK it belongs in your consent setup like any analytics script. Starter is $49 a month, Growth is $149 with session recordings and a 7-day free trial, and Scale is $349.

Key takeaways

First-party is a statement about the domain, not about privacy or the law. Safari limits first-party cookies most: cookies written by JavaScript and all script-writeable storage, including local storage, are deleted after 7 days without interaction, and cookies written by JavaScript on a landing page reached through a detected decorated link are capped at 24 hours. Cookies set by your own server avoid the 7-day script rule, though Safari caps their expiry at 7 days if it detects third-party CNAME or IP cloaking. Chrome caps every cookie's expiry at 400 days. EU law requires consent to store or read information on a device whichever party sets it, and the UK's newer statistical exception does not cover linking a purchase to an advert.

What a first-party cookie is

MDN, Mozilla's developer documentation, gives the working definition: if the cookie's domain and scheme match the page the user is looking at, it is a first-party cookie; if they differ, it is a third-party cookie. A first-party cookie can be set on the first visit, on an internal link or when the page requests a resource from the same site.

A first-party cookie is created in one of two ways: the server sends it in a Set-Cookie header, or JavaScript on the page writes it through document.cookie. Only the first can carry the HttpOnly attribute, which MDN describes as keeping the cookie out of reach of JavaScript so that it is only sent to the server. Safari treats the two routes differently.

First-party vs third-party cookies

Third-party cookies made cross-site tracking possible, because an ad server embedded on many sites could recognise the same browser everywhere. MDN's guide to third-party cookies summarises where browsers stand. Firefox enables Total Cookie Protection by default, giving third-party cookies a separate cookie jar per site. Safari blocks third-party cookies under its tracking prevention policy. Chrome does not block third-party cookies by default, only in Incognito mode or when users choose to.

Chrome's position is settled for now. In an update dated 17 October 2025, Google confirmed it is keeping its current approach to third-party cookie choice and said it would retire most Privacy Sandbox technologies, including the Attribution Reporting API, Topics and Protected Audience, citing low adoption. Our guide to cookie deprecation covers what that changed.

How browsers limit first-party cookies

Safari

WebKit's tracking prevention documentation sets out the rules that matter to a store. All cookies created in JavaScript, and all other script-writeable storage, are deleted after 7 days of no user interaction with the website. The storage covered includes local storage, session storage, IndexedDB, media keys and service worker registrations and caches.

A stricter rule applies to click identifiers. WebKit says some trackers add click IDs as URL parameters and read them with JavaScript on the landing page, and that when ITP detects this link decoration it caps the expiry of cookies created in JavaScript on that landing page to 24 hours.

Server-set cookies are not exempt in every case. WebKit says ITP detects third-party CNAME cloaking and third-party IP address cloaking and caps any cookies set in those HTTP responses to 7 days. A subdomain such as track.yourstore.com that resolves to an analytics vendor's domain is the typical example.

Firefox

Firefox's limits fall mostly on third parties. Mozilla's help centre says Standard Enhanced Tracking Protection blocks social media trackers, cross-site tracking cookies, fingerprinters and cryptominers, and that Total Cookie Protection, enabled by default, confines every cookie to the website where it was created. MDN's documentation on state partitioning says dynamic partitioning has been on by default for all users since Firefox 103.

Firefox's redirect tracking protection also clears cookies and site data set by known trackers, unless the user has interacted with that site as a first party in the last 45 days. That affects tracker domains, not a store's own cookies.

Chrome

Chrome's rule is a ceiling. Since Chrome 104, released in August 2022, a cookie cannot set an expiry more than 400 days in the future; a longer expiry is not rejected but is set to 400 days instead.

Server-set versus script-set cookies

Google Analytics 4 is a useful example of the script-set kind. Its tags use first-party cookies to tell users and sessions apart, and the _ga cookie has a default expiry of two years. Google's own documentation notes that browsers limit this to 400 days in Chrome and 7 days in Safari if the user does not return. Our guide to server-side tracking for e-commerce covers the server route in more depth.

Consent rules in the EU and the UK

The EU rule is Article 5(3) of the ePrivacy Directive. It allows storing information, or gaining access to information already stored, on a user's device only with their consent after clear and comprehensive information, except where it is purely to transmit a communication or strictly necessary for a service the user explicitly asked for. It says nothing about first or third party. The European Data Protection Board's guidelines on its technical scope, adopted on 7 October 2024, add that the rule covers storage placed through the browser's own mechanisms, such as cookie storage, and that information held in cookies or local storage is caught once it, or anything derived from it, is accessed rather than staying on the device.

National regulators read that rule in their own ways. France's CNIL, for example, exempts audience measurement cookies from consent under strict conditions, including a single site, no combining with other data, a truncated IP address and a tracker lifetime of no more than 13 months.

The UK changed its rules after the Data (Use and Access) Act 2025, and the ICO finalised its guidance on storage and access technologies on 29 April 2026. PECR now has a statistical purposes exception for analytics that produce aggregate information to improve a site, with a simple, free way to object. The ICO is explicit that it does not cover advertising, and that you still need consent to link a user's activity and purchase journey on your website to an online advert they clicked.

For a store, that is the key point: the ICO treats measuring which ad brought an order as advertising measurement that needs consent whether the cookie is first-party or not, and neither Article 5(3) nor the CNIL exemption offers an EU route around it. Our guide to Global Privacy Control covers the browser opt-out signal and what stores should do about it.

What this means for store attribution

For attribution, the Safari rules do the most damage. A visitor who clicks a Google or Meta ad lands with gclid or fbclid in the URL. If that identifier is kept only in a cookie written by JavaScript on the landing page, Safari may delete it after 24 hours, and anything in script storage goes after 7 days without user interaction with the site. A buyer who comes back in a week to complete the purchase then looks like a new visitor with no ad behind them.

Three things soften this: keeping the click identifier on your own server from the first page view, setting long-lived identifiers from your server rather than from script, and identifying the customer at checkout. None changes what needs consent.

How Arktis stores its identifiers

Arktis is the product we build, so weigh this accordingly. Its tracker keeps a visitor identifier and a session identifier in the browser's local storage from the first page view, and sends pageviews before consent, marked as not consented. It sets its own first-party cookies, _arktis_id for up to 365 days and _arktis_sid for one day, only after consent is recorded, either through its consent call or by reading, when the script loads, the consent cookie of a common consent manager such as Cookiebot, OneTrust, CookieYes or Osano. The cookies and the local storage entries are all written by script, so Safari's 7-day rule applies to them. Under Global Privacy Control, which Arktis honours by default, it keeps identifiers in session storage only and sets no cookies.

What that means for consent: the tracker's consent check covers its cookies and session recordings, not the local storage identifiers or the pageviews. Article 5(3) is not limited to cookies: the EDPB says storage through the browser's own mechanisms counts, and that information in local storage is caught once it, or anything derived from it, is accessed, which happens when the tracker sends its identifiers with each pageview, while the ICO applies its rules to web storage as it does to cookies. So in the EU and the UK, treat Arktis as needing consent: load its script through your consent manager only after the visitor agrees, as you would any analytics script.

The ad click identifiers it captures on landing, gclid, gbraid and wbraid from Google, fbclid from Meta, msclkid from Microsoft, ttclid from TikTok and others, together with UTM parameters, are held against the visitor on the server across sessions. Shopify orders arrive by webhook and are matched to a visit on email where the store has identified the visitor, otherwise on the UTM source of a session from the previous 24 hours, which can be another visitor's session. Unmatched orders are kept, unattributed.

Where Arktis does not fit

Arktis does not set server-side cookies, so in Safari a visitor who stays away for more than 7 days can return as a new visitor; if the store identifies them by email, a later order can still be matched to the new visit, but Arktis does not join it to the earlier one. It identifies visitors per browser and does not join one person across devices. It does not send events to Meta's Conversions API or Google enhanced conversions, which some stores use to recover conversions the browser misses. And local storage is not a way round consent: Arktis writes its identifiers there as soon as it loads, so it cannot run as a consent-free setup.

Measure on your own first-party data

To see which UTM campaigns and ad platforms brought your orders, start the 7-day Growth trial, or compare the tiers on the pricing page. For the bigger picture, read our first-party data strategy guide and Matomo vs Google Analytics.

Sources

MDN: third-party cookies, first-party and third-party definitions and browser defaults, and MDN: using HTTP cookies, Set-Cookie, document.cookie and HttpOnly, accessed 16 October 2026

WebKit: tracking prevention in WebKit, the 7-day cap on script-writeable storage, the 24-hour link decoration cap, cloaking defence and third-party cookie blocking, accessed 16 October 2026

Mozilla Support: Enhanced Tracking Protection in Firefox, Standard mode and Total Cookie Protection, accessed 16 October 2026

MDN: state partitioning and redirect tracking protection, Firefox 103 default and the 45-day interaction rule, accessed 16 October 2026

Chrome for Developers: cookie expiry capped at 400 days, from Chrome 104 in August 2022, and Privacy Sandbox: update on plans, dated 17 October 2025, accessed 16 October 2026

Google Analytics Help: cookie usage on websites, first-party cookies, the two-year _ga default and browser limits, accessed 16 October 2026

ePrivacy Directive 2002/58/EC, consolidated text, Article 5(3), accessed 16 October 2026

EDPB Guidelines 2/2023 on the technical scope of Article 5(3), version 2.0 adopted 7 October 2024, storage and local storage, accessed 16 October 2026

ICO: what are the exceptions?, the statistical purposes exception and the consent needed for advertising measurement, and ICO: what are storage and access technologies?, web storage covered by PECR, guidance last updated 29 April 2026, accessed 16 October 2026

CNIL: use analytics on your websites and applications, conditions for the analytics consent exemption, accessed 16 October 2026