The GA4 _ga Cookie: Everything You Need to Know (and the May 2025 Change)

The Silent Change of May 2025

In May 2025, Google modified the _ga cookie format without an official announcement. The old GA1.x format, used since GA4’s early days, was replaced by a new GS2.x format. This change silently broke dozens of third-party tools, custom scripts, and GTM templates that parsed the _ga cookie to extract the client_id.

The old format was simple and predictable: GA1.2.1234567890.1678901234. Two version digits, followed by two numeric components separated by dots. The client_id corresponded to the last two segments.

The new GS2 format uses a radically different structure: labeled key-value parameters with $ separators. The cookie now contains additional metadata about consent, timestamps, and stream ID, all encoded in a compact string.

Anatomy of the New GS2 Cookie

The GS2 format encodes multiple pieces of information in a single cookie. It contains the client_id (still present, but in a labeled segment), the first visit timestamp, the current session timestamp, the session count, and consent-related flags.

The parsing logic changes completely. Instead of a simple split on the dot and taking the last two segments, you now need to identify segments by their label and then extract the associated value. Julius Selnekovič’s GTM template is currently the reference for parsing this new format in a server-side container.

The practical impact is significant. If you have custom scripts that read the _ga cookie for homemade cross-domain tracking, server-side Cookie Restore, or CRM reconciliation, those scripts are likely broken since May 2025. The solution is to migrate to the new parsing or, better yet, stop parsing the cookie yourself and let the GA4 library handle client_id extraction via the gtag get API.

Safari ITP and Cookie Lifespan

The _ga cookie is a first-party cookie, meaning it is set on your own domain. But browsers do not treat all first-party cookies the same way.

On Chrome, the _ga cookie has a maximum lifespan of 400 days, renewed with each visit. A Chrome user who visits your site once a month retains the same client_id indefinitely.

On Safari, the situation is radically different. Intelligent Tracking Prevention (ITP) limits first-party cookies set via JavaScript to a 7-day lifespan. If a Safari user does not return within 7 days, their _ga cookie expires and they receive a new client_id on their next visit. It is as if they were a new user. Worse: cookies set via document.cookie in a context identified as tracking are limited to 24 hours.

The impact on your metrics is direct: unique user count is overestimated, return rate is underestimated, and multi-session attribution is truncated for all Safari users. Given that Safari represents between 25 and 35% of web traffic in many markets (even more on mobile), this is a massive bias.

The technical workaround is to set the cookie via a server-side HTTP Set-Cookie header rather than via JavaScript. Server cookies are not subject to ITP’s 7-day limitation. This is exactly what server-side tracking enables with the Cookie Restore feature, configurable during an advanced GA4 and GTM setup.

Consent Mode and Cookieless Pings

When a user refuses cookie consent and you have configured Consent Mode v2 in Advanced mode, GA4 does not set any cookie. No _ga, no _gid, nothing. But GA4 still sends anonymized pings to Google’s servers.

These cookieless pings contain limited information: the timestamp, the page visited, and aggregated signals (screen size, language). Google uses these pings to feed its machine learning models and estimate missing conversions. This is called behavioral modeling.

The key takeaway: in Advanced Consent Mode, you have no cookies, but you still get modeled data in GA4. The quality of this modeling depends directly on the volume of consented traffic you collect. The higher your consent rate, the more reliable the model.

The _ga Cookie in the Cross-Domain Ecosystem

The _ga cookie is the only GA4 cookie involved in cross-domain tracking. Other cookies (_gid, _ga_STREAM) are specific to a data stream and are not transferred between domains. When a user moves from one domain to another with cross-domain configured, it is the client_id extracted from the _ga cookie that is transmitted via the _gl parameter in the URL.

With the GS2 format change, this mechanism remains identical in principle, but the _ga cookie parsing on the receiving end must be compatible with the new format. For standard implementations via gtag.js or GTM, Google handles this compatibility automatically. For custom implementations, the update is your responsibility. If in doubt, check the first-party cookie glossary for the fundamentals.