What is First-Party Cookie?

It depends on the address bar

Whether a cookie is first-party is a property of the context, not of the cookie itself. A first-party cookie is set by the site the user is actually visiting, the one in the address bar. The same video platform's cookie is first-party while the user is on the platform's own site, and a third-party cookie when it arrives through an embedded player on someone else's page.

Browsers usually draw the line using the notion of a “site”: the scheme plus the registrable domain. www.example.com and shop.example.com are the same site; example.com and example-cdn.net are not. A cookie shared between two domains owned by the same company is therefore cross-site in the browser's eyes.

Server-set versus script-written

There are two ways to create one. The server sends a Set-Cookie header, which allows attributes such as HttpOnly and is the right place for session cookies. Alternatively, JavaScript on the page writes to document.cookie, which is how most analytics tags work.

// An analytics script writes its own visitor ID on the domain being visited
document.cookie = "visitor_id=5c1e9a; Max-Age=31536000; Path=/; Secure; SameSite=Lax";

The _ga cookie of Google Analytics 4 is a familiar example of this model: it lives on the site's own domain and is technically first-party.

First-party is not the same as private

A widespread assumption is that first-party cookies are automatically privacy-friendly and need no consent. Yet in the example above, the ID in the cookie travels to the analytics vendor's servers with every measurement hit. Legal assessments look at purpose and at who receives the data, not at which domain the cookie sits on.

Turkey's data protection authority, for instance, accepts that first-party analytics may rely on a basis other than consent only under conditions: anonymous statistics, IP masking, no cross-site tracking, a reasonable cookie lifetime and no onward sharing with third parties. Setups that fall outside such conditions belong behind cookie consent.

Browsers cap first-party cookies too

Safari's Intelligent Tracking Prevention does not stop at third-party cookies. According to WebKit's published policy:

• cookies created in JavaScript, and other script-writeable storage, are deleted after 7 days without user interaction with the site;
• when a visitor arrives through a link decorated with tracking parameters, cookies written by JavaScript on the landing page are capped to 24 hours;
• when a third-party service is disguised as first-party through a CNAME record (CNAME cloaking), cookies set in those responses are capped to 7 days.

The practical effect is that Safari users show up more often as “new” visitors and returning-user rates are understated. Workarounds designed to defeat these caps run against user expectations; accepting a margin of error in measurement is the healthier choice. WebKit keeps the details current on its tracking prevention page.

Safe defaults for session cookies

A first-party cookie that carries a login session should be HttpOnly, Secure, restricted with SameSite (Lax or Strict) and, where possible, named with the __Host- prefix so that subdomains cannot overwrite it.