The _ga, _gid and _gat cookies explained: purpose, lifetime and GDPR consent

If you have opened your browser's developer tools or a cookie scanner and found a row of cookies starting with _ga, you are not alone. They are among the most common cookies on the web, and also among the most misunderstood. This guide explains what each one does, how long it really lives, what European regulators say about it and what changes when you use Google Consent Mode v2.

The Google Analytics cookies at a glance

Google documents its analytics cookies in two official places: the GA4 help article on cookie usage on websites and the Google advertising and measurement cookie reference. Combined, they give the following picture:

For the tag configuration side, our Google Analytics 4 service page covers Consent Mode and the settings that matter for the GDPR.

• _ga: default lifetime 2 years. Used to distinguish users. It contains a randomly generated client ID, not your name or email address.
• _ga_<container-id>: default lifetime 2 years. Used to persist session state (for example _ga_ABC123XYZ, where the suffix is your measurement ID without the G- prefix).
• _gid: lifetime 24 hours. Listed by Google as an analytics cookie used to distinguish users over a single day. It belongs to Universal Analytics.
• _gat (or _gat_<custom name>): lifetime 1 minute. Historically used by Universal Analytics to throttle the request rate on busy sites.

All four are first-party cookies: they are written on your own domain by Google's JavaScript, not on google.com. That technical detail does not change the legal analysis, as we will see below.

Meta's _fbp and _fbc cookies work the same way, as our article on the _fbp and _fbc cookies explains.

_ga and _ga_<container-id>: the two cookies GA4 really uses

Google's current GA4 cookie table lists exactly two cookies: _ga and _ga_<container-id>. The first identifies a browser across visits so that GA4 can count users rather than hits. The second stores session information such as the session ID and session count, which is how GA4 knows whether two page views belong to the same visit.

The "2 years" figure is a default, and it is a rolling one. According to Google's tag configuration reference, every time a hit is sent the expiry is reset to the current time plus the cookie_expires value (63,072,000 seconds by default). In practice, a visitor who comes back once a month keeps the same _ga cookie indefinitely. You can shorten this with the cookie_expires setting, and you can stop the automatic refresh with cookie_update: false.

If your GA4 property is linked to Google Ads, the tag can also set advertising cookies such as _gcl_au (90 days according to Google's cookie reference). For a deeper look at the GA4 setup itself, see our guide on GA4 cookies and GDPR compliance.

Does GA4 still set _gid and _gat?

Short answer: not according to Google's documentation. The GA4 cookie article mentions only _ga and _ga_<container-id>. _gid and _gat were set by analytics.js, the Universal Analytics library, and Universal Analytics stopped processing data in 2023 before being fully shut down on 1 July 2024.

So if a scan of your site still finds _gid or _gat, treat it as a signal worth investigating rather than normal GA4 behaviour. Common causes include:

Our complete guide to website cookie audits shows how to inventory every cookie and trace it back to the script that sets it.

• an old analytics.js snippet still hard-coded in a theme, footer or landing page template;
• a plugin, extension or third-party widget that ships its own legacy tracking code;
• an old Universal Analytics tag still published in Google Tag Manager;
• a cookie scanner whose database is outdated and labels cookies by name rather than by what the page actually sets.

Removing dead code is good hygiene anyway: a tag that sends data to a property that no longer exists still loads scripts, still writes cookies and still has to be covered by your consent banner.

Why the _ga cookie needs consent under GDPR and ePrivacy

The legal trigger is not the GDPR alone but Article 5(3) of the ePrivacy Directive: storing or reading information on a user's device requires prior consent, unless it is strictly necessary for a service the user explicitly requested. Analytics is useful to you, but it is not necessary for the visitor to read your page. The Court of Justice of the EU confirmed in Planet49 (C-673/17, 2019) that this rule applies whether or not the stored information is personal data, and that pre-ticked boxes are not valid consent.

On top of that, the client ID in _ga is a unique identifier tied to a device, which makes the subsequent processing personal data under the GDPR. The EDPB's Guidelines 2/2023 on the technical scope of Art. 5(3), adopted in their final version in October 2024, also make clear that the rule covers more than cookies: pixels, local storage and similar techniques are in scope too.

What about the audience measurement exemption?

Several regulators accept that some analytics can run without consent, but under strict conditions. The French CNIL and the Spanish AEPD, for example, require that the tool be used solely for the publisher's own audience measurement, that it produce anonymous statistics only, that data not be shared with or reused by third parties, that cookies last no more than 13 months without automatic renewal and that data be kept for no more than 25 months. The CNIL states that most large audience measurement offerings do not fall within this exemption, whatever their configuration. A rolling 2-year _ga cookie, combined with a provider that can use data for its own purposes, does not fit that model.

Matomo is a common example of a tool that can be configured to meet these conditions, as our article on Matomo and cookie banners explains.

The UK is a partial exception. Since the Data (Use and Access) Act 2025, the ICO's guidance describes a "statistical purposes" exception for analytics, but only if the provider acts solely on your behalf, the information is aggregated and visitors get a simple, free way to object. Check those conditions carefully before relying on them for Google Analytics. Our article Is Google Analytics GDPR compliant? covers the wider debate, including international data transfers.

How Consent Mode v2 changes cookie behaviour

Google Consent Mode lets your consent banner tell Google tags what the visitor accepted, using four signals: analytics_storage, ad_storage, ad_user_data and ad_personalization. The last two were added with v2. For the _ga family, analytics_storage is the one that matters.

According to Google's Consent Mode documentation, when analytics_storage is denied, Google tags do not read or write first-party analytics cookies. No _ga, no _ga_<container-id>. What happens next depends on the implementation:

• Basic mode: Google tags are not loaded at all until the visitor makes a choice. Nothing is sent to Google before consent, not even the default consent state.
• Advanced mode: tags load with a default denied state and send cookieless pings (consent state, timestamp, user agent, events) without setting cookies. Google uses them for behavioural and conversion modelling.

Once the visitor clicks "Accept", the consent state switches to granted and GA4 writes _ga and _ga_<container-id> as usual. If they refuse, no analytics cookies are created. Bear in mind that cookieless pings still involve sending data from the visitor's browser to Google, so EU regulators may still view advanced mode as needing a careful legal assessment. Our comparison of Consent Mode basic vs advanced goes through the trade-offs.

If refusals leave too big a gap in your data, our guide to cookieless analytics reviews the options for measuring without consent.

Practical checklist for your website

1. Scan your site and list every _ga, _gid, _gat and _gcl_ cookie actually set, with the page where it appears.
2. Remove legacy Universal Analytics code if _gid or _gat still show up.
3. Block GA4 until consent, or use Consent Mode with analytics_storage set to denied by default for EEA visitors.
4. Check that refusal works: reject all cookies, reload, and confirm in the developer tools that no _ga cookie is created.
5. Document the cookies in your cookie policy with their real purpose and lifetime, and keep proof of each consent.
6. Consider a shorter lifetime via cookie_expires; the CNIL's 13-month benchmark is a useful reference, explained in our article on the 13-month cookie rule.

A consent management platform such as FlowConsent handles most of this list for you: it blocks scripts before consent, scans your site for cookies automatically, keeps consent records for 13 months and sends Google Consent Mode v2 signals out of the box, without needing Google Tag Manager. The Google Consent Mode setup guide shows the configuration step by step.

Conclusion

_ga and _ga_<container-id> are the only cookies GA4 is documented to set, and both live for a rolling two years by default. _gid and _gat belong to the past, and finding them today usually means old code is still running. In the EU, none of these cookies can be set before the visitor agrees, and Consent Mode v2 is the mechanism that makes GA4 respect that choice. Want to know which Google cookies your site sets right now? Run a free cookie scan with FlowConsent and see the result in under a minute.