Popular Cookies & Browser Storage Explained: What Websites Set Before You Consent

Every website you visit leaves small pieces of data on your device. Some are harmless and necessary, others track what you click, where you scroll, and what you almost bought. If you are a developer, agency owner or privacy professional, understanding these identifiers is the first step toward real GDPR compliance. This guide explains the most common cookies and browser storage entries we see in the wild — what they do, who owns them, and why they matter.

Cookies vs localStorage: what is the difference?

Cookies are small text files sent by a website and stored by your browser. They travel back to the server with every request, which makes them perfect for login sessions, shopping carts and tracking. localStorage and sessionStorage are newer browser APIs that store data only on the client side. They do not automatically leave the browser, but scripts can read them and include that data in outgoing requests. Under GDPR and the ePrivacy Directive, both cookies and storage access generally require consent unless strictly necessary.

The four cookie categories that matter

Regulators think in categories, not brand names. Here is the framework most CMPs use:

• Strictly necessary: required for the site to function — logins, carts, security tokens, consent choices.
• Preferences / functionality: language, currency, UI customizations, playback settings.
• Analytics: page views, events, session duration, funnel analysis.
• Marketing / advertising: retargeting, conversion tracking, audience building, cross-site profiling.

The legal line is simple: necessary cookies can fire before consent, everything else must wait for a clear affirmative action.

Google Consent Mode: the signals behind the banner

Google Consent Mode v2 introduced four storage keys that control how Google tags behave. They are not classic cookies, but they are stored in the browser and read by Google scripts:

• ad_storage — controls whether advertising cookies and identifiers can be read or written.
• ad_user_data — decides if user data can be sent to Google for advertising purposes.
• ad_personalization — controls whether data is used for personalized ads and remarketing.
• analytics_storage — governs analytics cookies, primarily Google Analytics 4.

When these keys are set to "granted" before the user clicks Accept, Google tags behave as if consent was given. If they are set to "denied" but marketing scripts still fire, you have a technical violation.

Google Analytics: _ga, _gid and _gat

Google Analytics is everywhere. The classic Universal Analytics cookies are still seen on many sites, even though GA4 is now the default:

• _ga — distinguishes users with a client ID, typically stored for 2 years.
• _gid — distinguishes users within a single day, stored for 24 hours.
• _gat — throttles request rate to Google servers, stored for 1 minute.
• _ga_* — GA4 session cookie that persists session ID and campaign attribution.

All of these fall under analytics and require consent under GDPR. They should not appear before the user agrees.

Advertising networks: Meta, TikTok, LinkedIn and more

Marketing cookies are the ones regulators worry about most, because they send personal data to external ad networks:

• _fbp, fr — Meta/Facebook Pixel. Stores browser ID and event data for retargeting and lookalike audiences.
• _ttp, _tt_ads, ttwid — TikTok Pixel. Tracks conversions and builds advertising audiences.
• personalization_id — X/Twitter. Used for ad personalization and measurement.
• _pin_unauth — Pinterest. Groups actions from users who are not logged into Pinterest.
• _scid — Snapchat Pixel. Identifies users for conversion tracking.
• UserMatchHistory, li_mc — LinkedIn. Syncs ad IDs and supports LinkedIn advertising.

These cookies often appear milliseconds after page load, long before the user has a chance to read the banner. That is exactly what a GDPR audit catches.

Session replay and heatmap tools

Tools like Hotjar and Microsoft Clarity record mouse movements, clicks and scrolls. Their cookies are analytics-adjacent but carry extra privacy risk because they can accidentally capture personal data typed into forms:

• _hjid, _hjSessionUser_*, _hjSession_* — Hotjar user and session identifiers.
• _clck, _clsk, CLID — Microsoft Clarity user and session identifiers.

Under GDPR, these usually require consent because they are not strictly necessary and may process personal data.

CMP cookies: the keepers of consent

Consent Management Platforms store the user's choices so the banner does not ask again on every page:

• OptanonConsent — OneTrust. Encoded consent string and audit timestamp.
• CookieConsent — Cookiebot. Consent level, timestamp and unique ID.
• didomi_token — Didomi. Encrypted consent choices and user identifier.
• uc_user_interaction — Usercentrics. Records whether the user interacted with the banner.
• cmp_* — Quantcast Choice. Encoded consent state.

These cookies are typically classified as necessary because they are required to remember consent. However, some implementations still send extra data or load additional scripts, which can be problematic.

How to check what your website actually sets

Reading about cookies is useful, but auditing a real website is better. Open your site in a clean browser session, do not click the consent banner, and inspect the Application tab in DevTools. Or use ConsentScope — it detects and explains cookies, storage writes and third-party scripts in real time, before consent.