A first-party cookie is a small piece of data stored in the browser by the same site the visitor is browsing, identified by the domain shown in the address bar. In cookies and consent practice, it is the cookie category that supports logins, shopping carts, language settings and on-site analytics, and it remains largely available after browsers began blocking third-party cookies.
Being first-party describes who sets and reads the cookie, not whether it is harmless. Under European privacy rules, a first-party cookie still needs prior consent unless it is strictly necessary for a service the user explicitly requested.
How a first-party cookie is set and read
A cookie is first-party when its domain matches the site of the top-level page. The server sets it with a Set-Cookie response header, or a script running on the page writes it through document.cookie. On later requests to the same site, the browser sends the cookie back automatically in the Cookie header.
Browsers compare sites using the registrable domain, also called eTLD+1. A cookie set for shop.example.com with Domain=example.com is shared across all subdomains, while a cookie from a different registrable domain loaded on the same page is third-party in that context.
The attributes below control the scope, lifetime and security of a first-party cookie.
| Attribute | Typical values | Effect |
|---|---|---|
| Domain | Omitted or parent domain | Host-only cookie or shared across subdomains |
| Path | / or a subdirectory | Limits which URLs receive the cookie |
| Expires or Max-Age | Session to about 400 days | Session cookie or persistent cookie |
| Secure | Present or absent | Sent only over HTTPS when present |
| HttpOnly | Present or absent | Hidden from JavaScript to limit theft by scripts |
| SameSite | Strict, Lax, None | Controls sending on cross-site requests |
Modern browsers cap persistent cookie lifetime at roughly 400 days, and some apply much shorter limits to cookies written by scripts. Safari, for example, restricts many script-set first-party cookies to seven days or less under its tracking prevention.
First-party and third-party cookies compared
The difference between first-party and third-party cookies lies in context, not in the cookie itself. The same cookie from an advertising domain is first-party when the user visits that domain directly and third-party when it is loaded inside another site.
| Property | First-party cookie | Third-party cookie |
|---|---|---|
| Set by | Site in the address bar | Embedded resource from another domain |
| Cross-site tracking | Not directly possible | Core use case |
| Browser support | Allowed by default | Blocked or restricted in major browsers |
| Typical uses | Sessions, carts, preferences, analytics | Ad targeting, retargeting, cross-site measurement |
| Consent requirement | Needed unless strictly necessary | Practically always needed |
A significant blind spot is CNAME cloaking and server-side tagging, where a third-party vendor operates under a subdomain of the site. Technically the cookie becomes first-party, but legally the vendor still receives the data, so consent and transparency obligations do not disappear.
Consent rules for first-party cookies
In the European Union, cookie consent derives from Article 5(3) of the ePrivacy Directive, which covers any storage of or access to information on the user’s device. The rule applies equally to first-party and third-party cookies; the only exemptions are cookies strictly necessary for transmission or for a service the user requested.
The table shows how typical first-party cookies are usually classified in a consent banner or CMP.
| Cookie purpose | Consent category | Consent needed |
|---|---|---|
| Session login | Strictly necessary | No |
| Shopping cart | Strictly necessary | No |
| Load balancing | Strictly necessary | No |
| Consent record itself | Strictly necessary | No |
| Language or theme preference | Functional | Often yes, depends on authority guidance |
| Web analytics identifier | Statistics | Yes in most member states |
| Advertising identifier | Marketing | Yes |
Some authorities accept audience measurement cookies without consent when they are strictly limited, produce only aggregated statistics and are not shared or combined with other data. This exemption is national and conditional, so it must be verified for each market rather than assumed.
Practical design of first-party cookies
Good first-party cookie design starts with data minimization: store an opaque identifier, not personal details, and keep the actual data on the server. A cookie should carry no email address, name or plain-text token that could be read by an attacker or an extension.
- Set Secure and HttpOnly on every session and authentication cookie.
- Use SameSite=Lax as the default and Strict for sensitive actions.
- Prefer host-only cookies and widen the Domain attribute only when subdomains truly need them.
- Choose lifetimes that match the purpose, such as hours for sessions and months for preferences.
- Write non-essential cookies only after consent is recorded, not on page load.
Common mistakes with first-party cookies
Many compliance and security problems come from the assumption that first-party means exempt. The table lists typical errors and their remedies.
| Mistake | Consequence | Fix |
|---|---|---|
| Analytics cookies set before consent | Breach of consent rules | Load analytics tags only after opt-in |
| Session cookie without HttpOnly | Session theft through injected scripts | Add HttpOnly and Secure flags |
| Vendor cookies under own subdomain | Hidden third-party processing | Disclose and gate behind consent |
| Multi-year expiry for preferences | Excessive retention | Shorten lifetime to the real need |
Put simply
A first-party cookie is a small note that a website leaves in your browser so it can recognize you on your next click or visit. It is written and read only by the site you are actually on, which is why it can remember that you are logged in or what is in your basket.
It works like a cloakroom ticket from the venue you are visiting. The ticket is useful there and nowhere else. Still, the venue must ask before using the ticket for anything beyond the service you came for, such as counting your visits or targeting you with ads.
In practice
A regional online shop audits its cookies after customers complain about a slow, cluttered banner. The scan finds eleven first-party cookies: a session cookie, a cart cookie, a consent record, a currency preference, two analytics identifiers and five cookies written by a marketing tag running on a shop subdomain.
The team keeps the session, cart and consent cookies outside the banner as strictly necessary and adds HttpOnly, Secure and SameSite=Lax to the session cookie. It moves the analytics identifiers into the statistics category, shortens their lifetime from two years to thirteen months and loads the tag only after opt-in. The five marketing cookies are disclosed as vendor cookies and placed under the marketing category.
The outcome is a shorter, accurate banner and no cookies set before consent, while checkout and login continue to work for every visitor regardless of their choice.