Update time: May 30, 2026
If you’ve ever opened your browser’s developer tools while debugging GA4 tracking and stared at a list of cookies like _ga, *ga*<container-id>, or FPID without knowing what each part means… you’ve come to the right place.
GA4 uses up to four main cookies to handle user identification, session management, and cross-site tracking. But the expiration you see in the documentation doesn’t always match what you’ll find in practice, and the structure of each cookie can look like alphabet soup at first glance.
In this guide, I’ll break down each GA4 cookie — what it does, what its value actually means, and when you’ll encounter it — using real examples.
GA4 Cookie Overview
Here’s a quick reference table for the four main GA4 cookies:
| Cookie name | Default expiration time | What it does |
|---|---|---|
| _ga | 2 years | Distinguishes users |
| _ga_<container-id> | 2 years | Persists session state |
| FPID | 2 years | Distinguishes users (server-side) |
| FPLC | 20 hours | Enables cross-domain tracking (server-side) |
Note: GA4 cookies are configured with a 2-year expiration by default, but most browsers cap first-party cookies at 400 days (~13 months). In practice, the effective cookie lifetime is usually around 400 days, not 2 years.
_ga Cookie Explained
By default, GA4 assigns a unique Client ID to each device. That Client ID is stored in the _ga cookie. Here’s what it looks like:
GA1.1.1197596843.1673515099
The value after GA1.1. — in this case, 1197596843.1673515099 — is the Client ID.
Let’s break each part down:
| Value | Description |
|---|---|
| GA1 | Version number (cookie format version) |
| 1 | Domain level (GA4 almost always uses 1) |
| 1197596843 | Random 10-digit number |
| 1673515099 | Timestamp of when the _ga cookie was created |
So when you see GA1.1.1197596843.1673515099, you now know it means: version GA1, domain level 1, a random user identifier 1197596843, and that user was first seen at Unix timestamp 1673515099.
_ga_<container-id> Cookie Explained (Session Cookie)
The _ga_<container-id> cookie is GA4’s session cookie. It maintains the current session state. Here’s an example value:
GS2.1.s1673933110$o12$g0$t1673933110$j60$l0$h0$riYSmWx3uWvuJEDkCvwJCnvET7QcvFq7kg
That’s a lot of numbers. Let me walk through each field:
| Value | Description |
|---|---|
| GS | Fixed identifier (Google Session). |
| 2 | Analysis version (commonly 1 or 2). |
| 1 | Domain level (almost always 1). |
| 1673933110 | Session ID — the start time of the current session |
| 12 | Session count for the user. |
| 0 | Engagement session flag (1 = engaged, 0 = not engaged). |
| 1673933110 | Current Timestamp |
| 60 | Countdown，60-second countdown, cookie and user data matching/syncing when Google Signals is enabled |
| 0 | User-ID status (1 = logged in with User-ID set). |
| 0 | Enhanced Client ID (ecid) — only has value with server-side tracking or User-ID + user-provided data collection enabled |
| riYSmWx3uWvuJEDkCvwJCnvET7QcvFq7kg | This field is available when Google signals data collection is enabled and indicates the Google signals or the associated ID of the Google signals. |
Important: On the very first request of a session, the Session ID and Current Timestamp will be identical — because the Session ID is the session start time.
FPID Explained (First-party Device ID)
FPID (First-party Device ID) only comes into play with server-side GTM. If you’re using client-side GA4 only, you won’t see it.
Here’s an example FPID value:
FPID2.2.F99Fd7gVuQuP93MZdJiEn07o/eZba6j9bAt8ETLsn8E=.1733280703
Note that F99Fd7gVuQuP93MZdJiEn07o/eZba6j9bAt8ETLsn8E=.1733280703 is also treated as a form of Client ID in GA4’s backend.
Let’s break it down:
| Value | Description |
|---|---|
| FPID2.2 | Version number |
| F99Fd7gVuQuP93MZdJiEn07o | Core user identifier |
| eZba6j9bAt8ETLsn8E= | Additional security or validation data |
| 1733280703 | Timestamp |
FPLC Explained
You may also encounter a cookie named FPLC. It’s the less-talked-about cousin of FPID, so let me explain why it exists and what it does.
Why FPLC Exists
FPID is set as HttpOnly, which means GTM and JavaScript cannot read it. That’s good for security, but it creates a problem: without JavaScript access, you can’t use FPID for cross-domain tracking.
That’s where FPLC comes in.
What FPLC Does
- FPLC is a hashed value derived from the FPID
- It is not HttpOnly, so JavaScript can access it
- It enables cross-domain tracking in GA4 when using server-side tagging
- It has a short lifetime of 20 hours
Think of FPLC as the JavaScript-readable bridge that makes cross-domain user stitching possible when you’re on a server-side setup. Without it, a user moving from example.com to checkout.example-pay.com would look like two different people.
Final Words
I hope this guide helped you make sense of GA4’s cookie structure. Cookies like _ga, *ga*<container-id>, FPID, and FPLC might look cryptic at first, but once you know what each segment means, they become a lot less intimidating.
If you’re debugging tracking issues or setting up cross-domain or server-side tracking, understanding these cookies will save you a lot of head-scratching.
