Magento 2 cookie consent starts with Cookie Restriction Mode, Magento's built-in notice, but that mode only holds back what Magento itself controls: its own non-exempt cookies and its native Google Analytics module. Tracking added by extensions, templates or layout XML runs regardless. A Magento store that sells to EU or UK visitors therefore needs a consent tool, Google Tag Manager consent settings or script blocking for everything the mode cannot see.
Why Magento stores face a particular cookie consent challenge
Magento (now Adobe Commerce, with Magento Open Source alongside it) differs from most e-commerce platforms in one way: its extension ecosystem. Many stores run dozens of third-party extensions, and each can set its own cookies without the store owner noticing. Payment gateways, analytics tools, recommendation engines, live chat widgets and marketing pixels all add to a cookie footprint the built-in notice was never designed to handle.
Under Article 5(3) of the ePrivacy Directive, storing or reading information on a visitor's device needs prior informed consent unless the cookie is strictly necessary. A default Magento installation offers Cookie Restriction Mode, but it does nothing to detect or block the tracking scripts that extensions inject into your storefront.
The enforcement risk is real. On 1 September 2025 the CNIL fined SHEIN 150 million euros for placing advertising cookies before visitors made a choice and for continuing to place them after a refusal. Online retailers are firmly in regulators' sights, and the e-commerce cookie rules apply to Magento stores like any other.
What Magento's Cookie Restriction Mode does
Magento Open Source and Adobe Commerce include Cookie Restriction Mode, switched on under Stores > Settings > Configuration > General > Web > Default Cookie Settings. When it is on, the storefront shows a notice asking visitors to allow cookies. Magento treats its own cookies as exempt or non-exempt and holds back the non-exempt ones until the visitor allows them. The choice is stored in the user_allowed_save_cookie cookie, kept for one year by default.
The mode does reach one tracking tool: Magento's own Google Analytics module. In Magento's Google Gtag code, when Cookie Restriction Mode is on, the GA4 tag loads only after user_allowed_save_cookie shows that the visitor allowed cookies for the current website. Google Analytics added through the store configuration therefore waits.
Everything else does not. Google Analytics added by an extension or a template, the Meta Pixel, and any JavaScript injected through layout XML or template overrides run independently of the mode. A visitor who has not consented may already have _fbp and several other tracking cookies on their device. The mode also offers a single allow button rather than a choice by category, so visitors cannot accept analytics while refusing marketing.
Identifying every cookie your extensions set
Before you can manage consent, you need a complete inventory of what your store sets. There are two practical approaches.
Manual auditing with browser DevTools
Open your storefront in Chrome, go to DevTools (Application > Cookies) and browse your key pages: homepage, category, product detail, cart and checkout. Record every cookie's name, domain, duration and purpose. Repeat in a private window to capture first-visit behaviour. This is thorough but slow, and you will need to repeat it every time you add or update an extension.
Automated cookie scanning
A cookie scanner loads your pages, finds cookies and other browser storage, and sorts them into categories. It catches cookies set by asynchronous scripts, lazy-loaded widgets and conditional logic that a manual audit can miss. Scheduled scans keep the inventory current as extensions update.
The table shows cookies commonly found on Magento stores with popular extensions:
| Cookie name | Set by | Category | Consent needed |
|---|---|---|---|
PHPSESSID | Magento core | Strictly necessary | No |
form_key | Magento core | Strictly necessary | No |
user_allowed_save_cookie | Magento core | Strictly necessary (stores the choice) | No |
mage-cache-sessid | Magento core | Functional | Jurisdiction-dependent |
_ga, _ga_<container-id> | Google Analytics 4 | Analytics | Yes |
_fbp | Meta Pixel | Marketing | Yes |
__kla_id | Klaviyo | Marketing | Yes |
_hjSessionUser_* | Hotjar | Analytics | Yes |
NID | Google reCAPTCHA | Functional | Debated |
mage-cache-storage, which many guides list as a cookie, is not one: Magento's customer data code keeps it in the browser's local storage, next to the customer section data, and uses the mage-cache-sessid cookie to know when to refresh it. Local storage still falls under Article 5(3), so it belongs in your inventory.
Content Security Policy and cookie consent
Magento 2.4 ships a Content Security Policy (CSP) that its checkout module configuration enforces on the checkout page, while the rest of the storefront runs it in report-only mode by default. CSP decides which external domains may load scripts, styles and other resources, and that affects cookie consent more than many store owners expect.
If your consent tool loads from its own domain, or releases tracking scripts from other domains after consent, those domains must be allowed in your CSP. Otherwise the browser blocks them on the pages where CSP is enforced, even after the visitor consents, and the banner or the tag silently fails.
Add the consent tool's domain and any conditionally loaded third-party domains to the relevant directives in your module's csp_whitelist.xml file. Kukie.io's guide to Content Security Policy lists the domains its banner needs. Test in a staging environment first: a policy that is too strict breaks functionality, and one that is too loose defeats its purpose.
Blocking extension scripts until consent is given
The core technical challenge on Magento is stopping third-party scripts from running before the visitor makes a choice. There are three approaches, each with trade-offs.
Script type attribute swapping
Change the type attribute of tracking scripts from text/javascript to text/plain and add an attribute naming the cookie category. The consent tool then runs the scripts for the categories the visitor accepted. With Kukie.io, that attribute is data-cc-category, for example data-cc-category="marketing". This works well for inline scripts and simple tags, but it means editing extension templates or overriding script blocks in layout XML.
Google Tag Manager as a consent layer
Move the third-party scripts into Tag Manager and set each tag's consent settings so it fires only once the right consent type is granted. With Google Consent Mode v2, Google's own tags adjust to the consent state. Non-Google tags need consent checks or triggers based on a dataLayer event from your consent tool. This centralises script management, but every extension's tracking code has to move out of Magento templates and into the Tag Manager container.
Blocking by a consent tool
A consent tool can block scripts without changes to extension code. Kukie.io's script blocking recognises more than 30 known trackers and holds them by category until the visitor consents, and you can add the domain of any other tracker an extension loads. For stores with many extensions, that saves most of the template work.
Google Consent Mode v2 on Magento
Since March 2024, Google has required Consent Mode v2 signals for advertising measurement and personalisation for traffic from the EEA and the UK. A standard Magento installation does not send Consent Mode signals: its native Google Analytics module waits for Cookie Restriction Mode instead, which is all or nothing. Without a consent tool or your own code sending the signals, Google limits what it can use from European visitors for conversion measurement and audiences.
Consent Mode v2 added two parameters to the original ad_storage and analytics_storage: ad_user_data and ad_personalization. Your consent tool passes all four to the Google tag (gtag.js or Tag Manager) based on the visitor's choices. In advanced mode, when consent is denied, Google's tags send cookieless pings that Google can use for conversion modelling, and full measurement resumes once consent is granted.
Classifying Magento core cookies correctly
Not every Magento cookie needs consent. Getting the classification wrong in either direction causes problems: over-blocking breaks checkout, under-blocking leaves trackers running.
PHPSESSID and form_key are strictly necessary. They keep the server session and protect forms against cross-site request forgery, and blocking them breaks the cart and checkout. mage-cache-sessid and the local storage entries it controls keep cached customer data fresh. They help the site but are not strictly needed for it to work, so some regulators may expect consent for them.
Product recommendation cookies, recently viewed trackers and comparison list cookies fall into the functional or analytics category depending on whether they feed a personalisation engine. If your recommendation extension uses cookies to build a browsing profile for personalised suggestions, those cookies need consent under the GDPR.
Payment gateway cookies and the strictly necessary exception
Magento stores usually integrate payment providers such as Stripe, PayPal, Braintree or Klarna. These set their own cookies for fraud detection, session management and device fingerprinting. Whether payment gateway cookies count as strictly necessary depends on what they do.
Cookies needed to complete a transaction the visitor explicitly asked for are generally exempt under Article 5(3) of the ePrivacy Directive. Fraud detection cookies set during checkout are usually considered essential. Cookies that persist after the transaction for remarketing or analytics are not.
Review each payment extension's cookie documentation and test what gets set at each stage of checkout. If a payment provider sets a persistent cookie on the product page before the visitor even reaches checkout, that cookie probably needs consent.
An implementation checklist for Magento 2
Work through these steps in order:
- Scan the whole storefront, including every page type and the checkout flow.
- Map every cookie found to the extension or script that sets it.
- Classify each cookie: strictly necessary, functional, analytics or marketing.
- Decide how scripts will wait for consent: a consent tool, Tag Manager consent settings or attribute swapping.
- Allow your consent tool and any conditionally loaded domains in your CSP configuration.
- Send Google Consent Mode v2 signals.
- Test that rejected cookies are actually blocked, not just hidden from the banner.
- Schedule repeat scans to catch new cookies from extension updates.
Check the result with Chrome DevTools. After rejecting all non-essential cookies, open the Application tab: no analytics or marketing cookies should be present. If they are, your blocking has a gap. The Magento cookie consent basics guide covers the first install in more detail.
Magento 2 cookie consent questions
Is Magento's built-in Cookie Restriction Mode enough for EU visitors?
Rarely. It holds back Magento's own non-exempt cookies and its native Google Analytics module, but not cookies set by extensions, templates or marketing pixels, and it offers no choice by category. Most production stores need a consent tool alongside it.
Does Cookie Restriction Mode block Google Analytics in Magento 2?
It blocks Google Analytics added through Magento's own Google Gtag module: that tag loads only after the visitor allows cookies. Google Analytics added by an extension, a template or Google Tag Manager is not covered and needs its own consent gate.
Which Magento cookies are strictly necessary and do not need consent?
PHPSESSID and form_key are strictly necessary for the session and form protection, and user_allowed_save_cookie stores the visitor's choice. Cart and checkout session cookies also qualify. mage-cache-sessid sits in a grey area that depends on your regulator's view.
Does Adobe Commerce's Content Security Policy affect cookie consent?
Yes. Magento 2.4 enforces its CSP on the checkout page and reports elsewhere by default. Your consent tool's domain and any conditionally loaded tracking domains must be allowed in csp_whitelist.xml, or the browser blocks them where the policy is enforced.
Are payment gateway cookies exempt from consent on Magento?
Cookies set by payment providers during an active checkout are generally strictly necessary. Cookies that persist beyond the transaction for fraud scoring, remarketing or analytics usually need consent under the ePrivacy Directive.
Scan your Magento store for extension cookies
Cookie Restriction Mode cannot tell you what your extensions set. The Cookie scanner loads your storefront like a visitor and lists every cookie it finds by name and category, so you can see which extensions still set cookies before a choice.
