Cookie Consent for Bubble.io: No-Code GDPR Setup

A Bubble.io app sets its own cookies on every visitor the moment a page loads, and it runs analytics, chat, and advertising scripts through marketplace plugins and a header field that fire before anyone has agreed to anything. Under EU and UK law, most of that has to wait for consent. Bubble hands you the slots to add tracking but nothing to hold it back, so consent on a no-code Bubble app is a job you assemble from three parts: Bubble's own default cookies, the scripts your plugins inject, and whatever you paste into the app header.

Does a Bubble.io App Need a Cookie Banner?

Yes, if it serves visitors in the EU or UK and sets any cookie beyond the strictly necessary. The rules that govern cookies attach to the visitor's location, not the tool that built the app, so a Bubble app meets the same standard as a hand-coded one. Article 5(3) of the ePrivacy Directive requires informed, prior consent before non-essential cookies are stored on a device. Bubble acts as a data processor for the data your app handles; you stay the controller responsible for lawful consent.

An app that only keeps a logged-in session running may fall inside the strictly necessary exemption. The moment you add analytics or a marketing pixel, prior consent applies, and the fact that Bubble built the front end changes none of that.

What Cookies Does Bubble Set by Default?

Bubble sets a small set of essential cookies on every user and visitor by default, used for authentication and core platform functions. According to the cookies Bubble sets by default, these keep a user logged in and link a visitor to their account once they sign up. The main ones are a session identifier, a session signature that protects the session against tampering, and a user identifier for the logged-in user. Because they exist to run the app the visitor asked for, they sit at the strictly necessary end of the scale, but Bubble also creates a temporary user record for logged-out visitors, which is where the default starts to matter.

Bubble exposes one control over this behaviour. The Do not set cookies on new visitors by default option lives under Settings > General, is off by default, and has to be set on each app. Switch it on and you can use workflow actions to opt a visitor in or out of Bubble's own cookies. This setting governs Bubble's cookies only and does nothing to the scripts your plugins load.

Where Does Tracking Actually Come From in a Bubble App?

Tracking in a Bubble app comes from two places, and Bubble gates neither. The first is installed plugins: a Google Analytics plugin, a Meta Pixel plugin, an Intercom or Hotjar plugin each inject their own script through Bubble's runtime, and they run when the page renders. The second is code you paste yourself, either into Settings > SEO/metatags > Script/meta tags in header for the whole app or into a single page's Page HTML Header. Whatever sits in those fields loads on render with no consent check in front of it.

This is the part that trips up people moving from a hand-built site. There is no template file to edit and no build step to hook into. A plugin that drops analytics cookies and a header snippet that sets third-party cookies behave the same way: they fire first and ask questions never. Custom scripts also only run on the live, deployed app, not in Bubble's preview mode, so a banner that looks absent in the editor may still be firing trackers in production.

Why No-Code Consent Differs From AI-Generated Apps

A tool that writes code for you leaves you with a codebase you own. When something like Cursor or Bolt scaffolds an app, you can move a tracking tag behind a consent check, wrap it in a condition, or delete it, because the file is yours to edit. Bubble takes that lever away. You assemble the app from plugins and settings, and the scripts those plugins inject run inside Bubble's runtime, which you cannot open up and rewrite. The gap between what AI builders leave out and what a visual builder like Bubble withholds is subtle but practical: one hands you code without consent logic, the other hands you no code to add consent logic to.

The compliance job in Bubble therefore splits cleanly. First, bring Bubble's own default cookies under control with the visitor setting. Second, put a consent layer in front of every plugin and header script, since Bubble supplies no way to defer them itself. A consent management platform that loads first and blocks the rest until a choice is recorded is the standard way to close that second half.

What Recent Enforcement Says About Pre-Consent Cookies

Regulators have been direct about cookies that fire before a visitor chooses, which is the exact default state of an untouched Bubble app. On 1 September 2025 the French regulator fined SHEIN EUR 150 million under Article 82 of the French Data Protection Act, which transposes the ePrivacy Directive. The decision turned on cookies, including advertising cookies, dropped as soon as visitors arrived and before they interacted with the banner, plus a reject all control that did not actually stop tracking. The same day, Google was fined EUR 325 million, its third CNIL cookie penalty after earlier fines in 2020 and 2021.

These are not isolated. The CNIL issued 83 sanctions worth roughly EUR 486.8 million across 2025, with cookie and tracker cases making up much of the total, including a separate EUR 1.5 million fine against American Express in November. A default Bubble app that sets its own cookies on arrival and loads plugin trackers on render sits squarely in the pattern the CNIL keeps sanctioning, even at a fraction of SHEIN's traffic, because the failure mode is the same: processing before choice.

How Do You Add GDPR-Compliant Consent to a Bubble App?

Bringing a Bubble app into line means closing both halves of the problem in order: Bubble's own cookies, then everything your plugins and header load. The steps below run from the platform settings outward.

1. Stop Bubble's pre-consent cookies. Enable Do not set cookies on new visitors by default under Settings > General, then attach workflow actions to your banner so a visitor's choice opts them in or out of Bubble's session cookies.

2. Inventory what actually loads. Run a cookie scan on the live app to list every cookie your plugins and header scripts set, then sort them into strictly necessary, analytics, and marketing groups.

3. Add the consent script first. Paste your consent management script as the top entry in Settings > SEO/metatags > Script/meta tags in header so it initialises before any other tag on every page.

4. Gate the trackers. Hold analytics and advertising cookies behind their categories, and configure Google Consent Mode v2 so Google Ads and GA4 receive a default-deny signal before they run for EEA and UK visitors.

5. Deploy and re-test. Push to live, since header scripts do not run in preview, and re-check the load order after every plugin install or template change, because a new plugin re-introduces an ungated script.

Settings > SEO/metatags > Script/meta tags in header
Consent management script   (loads first, blocks the rest)
Google Analytics / GA4      (fires only after analytics consent)
Meta Pixel                  (fires only after marketing consent)
Chat widget                 (fires only after functional consent)

Bubble-Specific Pitfalls to Check Before Launch

A handful of Bubble quirks quietly break consent even after the banner is in place. Walk through these before you publish.

• Reusable elements have no header. Code that belongs app-wide has to go in the SEO/metatags header field, not a reusable element, or it will not load everywhere.

• Plugins added later escape the gate. The consent layer only covers scripts that existed when you configured it. Installing a new analytics or chat plugin after launch adds a tracker that fires ungated until you route it through the banner.

• Preview hides the problem. Header scripts run on the live version only, so consent behaviour must be verified on the deployed URL, never judged from the editor.

• Subdomain moves reset cookie context. Shifting an app between a bubbleapps.io subdomain and a custom domain changes the first-party cookie context and can force visitors to re-consent or re-authenticate.

• The setting covers Bubble only. The Do not set cookies on new visitors toggle stops Bubble's own cookies, not the ones your plugins set, so it is one half of the job rather than the whole of it.

• Other regions bring other rules. Visitors from California, Brazil, or Canada trigger cookie rules in other regions that a single EU-style banner may not satisfy on its own.

Frequently Asked Questions

Add a Compliant Cookie Banner to Your Bubble App

If you are not sure what your Bubble app loads before consent, start by scanning the live version. Kukie.io detects the cookies your plugins and header scripts set, sorts them by category, and blocks non-essential scripts until a visitor chooses, which covers the half of the job Bubble leaves to you.

Start Free - Scan Your Bubble App