A FlutterFlow web app needs a cookie consent banner whenever it serves visitors in the EU or UK and stores anything non-essential on their devices. The banner goes in through the Custom Headers box in FlutterFlow's web publishing settings - no code export, no Dart changes, and no custom widget required.
That placement matters because a FlutterFlow web app is not an ordinary website. It is compiled Dart painted onto a canvas by Flutter's CanvasKit renderer, which means a consent layer built inside your widget tree cannot control the scripts loading around it. The banner has to sit in the HTML shell that bootstraps the app. This guide covers where that shell is, what a FlutterFlow app actually stores on a visitor's device, and how to stop Google Analytics firing before anyone has agreed to it.
Key takeaways:
FlutterFlow injects custom script tags into the head of your published app's
index.htmlthrough Settings and Integrations > Web Publishing > Custom Headers, which is where a consent banner belongs.Article 5(3) of the ePrivacy Directive covers all storage on a visitor's device, so Firebase Authentication entries in IndexedDB and app state in local storage fall under the same consent rules as cookies.
FlutterFlow's Google Analytics integration runs on Firebase Analytics, which sets
_gacookies on web builds and must stay blocked until the visitor consents under EU rules.France's CNIL issued 21 cookie-related sanctions in 2025, including EUR 150 million against SHEIN and EUR 325 million against Google, and enforcement has continued into 2026.
A banner injected via Custom Headers renders in the browser's DOM layer above the Flutter canvas, so it works without touching your Dart code.
Does a FlutterFlow Web App Need a Cookie Banner?
Yes, if the app is reachable from the EU or UK and stores or reads anything non-essential on a visitor's device. Article 5(3) of the ePrivacy Directive requires prior consent for that storage, and the General Data Protection Regulation (GDPR) sets the standard that consent has to meet: freely given, specific, informed, and unambiguous.
Where the app is hosted makes no difference. A project on a free flutterflow.app subdomain faces the same rules as one on a custom domain, because the law follows your visitors rather than your hosting plan. Pre-ticked boxes do not count. Neither does a banner where rejecting takes three clicks and accepting takes one.
The consent rule is also technology-agnostic. It talks about storing and accessing information on terminal equipment, not about cookies specifically - which matters more for Flutter apps than for most websites, as the next section shows.
What Does a FlutterFlow App Store on a Visitor's Device?
More than cookies. A typical FlutterFlow web app writes to IndexedDB for Firebase Authentication sessions, to local storage for app state saved through shared preferences, and to ordinary cookies once Google Analytics or a marketing pixel enters the picture. Each of those falls under the same storage-and-access rule, just with different consent outcomes.
| What gets stored | Mechanism | Typical purpose | Consent needed? |
|---|---|---|---|
| Firebase Authentication session | IndexedDB | Keeping a user signed in | No - strictly necessary for a service the user requested |
| App state via shared preferences | Local storage | Remembering in-app choices | Usually yes - preference storage is convenient, not strictly necessary |
Google Analytics 4 identifiers (_ga, _ga_XXXXXX) | Cookies | Usage measurement | Yes - prior consent before they are set |
| Third-party embeds in custom widgets (chat, maps, video) | Cookies and local storage | Marketing, personalisation | Yes - prior consent, per provider |
The European Data Protection Board (EDPB) settled any doubt about non-cookie storage in its Guidelines 2/2023 on the technical scope of Article 5(3), adopted in October 2024. The guidelines confirm the rule covers any information stored on or read from a device - personal data or not - including local storage entries, unique identifiers, and tracking pixels.
So an audit of your FlutterFlow app cannot stop at the cookie jar. Open the browser's developer tools on your published URL and check the Application tab: Cookies, Local Storage, and IndexedDB all count.
Why the Flutter Canvas Changes Where Your Banner Lives
A FlutterFlow web app renders its entire interface into a canvas element using Flutter's CanvasKit renderer, so there is no page template to drop a banner into the way there is on WordPress or Webflow. The consent layer instead lives in index.html, the small HTML shell that loads the compiled app.
That shell is where everything interesting happens before Flutter boots. The CanvasKit renderer, the app's compiled JavaScript, and any measurement scripts all load from there. A consent banner added as a plain script tag in the head draws its own DOM elements on top of the canvas, asks the visitor for a decision, and gates the tracking scripts loading beside it in the same shell.
Building the consent dialogue as a Flutter widget instead is a trap. Widgets only exist after the app has booted, and by then any script placed in the head has already run - your beautifully designed in-app dialogue would be asking permission for something that already happened. Enforcement decisions treat that ordering as a violation in itself, as the CNIL cases below show.
How Do You Add a Consent Banner to a FlutterFlow App?
Through Custom Headers, in four steps. FlutterFlow's web publishing documentation confirms anything entered there is placed inside the head tag of the generated index.html on the next publish.
Copy the banner embed tag from your consent platform. In Kukie.io this is a single script tag from the installation screen of your site's dashboard.
In FlutterFlow, open Settings and Integrations, go to Web Publishing, and paste the tag into the Custom Headers box. Put the consent script above any analytics tags you have added there, so blocking takes effect first.
Publish the app. Deployment takes a couple of minutes.
Verify on the live URL: press F12, confirm the tag sits inside the head element, then watch the Application tab to check nothing non-essential appears before you interact with the banner.
Two cautions from the same documentation. Malformed headers can break the page exactly as a bad manual edit to index.html would, so paste the tag unmodified. And Custom Headers only apply to the published app - Run Mode and Test Mode will not show your banner, so always verify against the live deployment.
What About FlutterFlow's Google Analytics Toggle?
FlutterFlow's built-in analytics option, under Settings and Integrations > Integrations > Google Analytics, wires your project to Firebase Analytics. On web builds that means gtag-based measurement and _ga cookies on the visitor's device - the exact category of storage that needs prior consent in the EU and UK.
The clean way to reconcile the two is Google Consent Mode v2: consent signals default to denied, the banner updates them when the visitor decides, and Google's tags adjust their behaviour accordingly. Consent Mode v2 has been required for audiences in the European Economic Area since March 2024 wherever Google's advertising features are in play. Kukie.io sends these signals automatically once its script is installed, which is why placing it above the measurement tags in Custom Headers matters.
If you skip Consent Mode, the alternative is blunter: keep the analytics toggle off for web, or block the measurement script entirely until consent is recorded. What you cannot do is let it fire on page load and mention it in a privacy policy afterwards.
What Recent Enforcement Means for App Builders
Cookie enforcement got dramatically heavier while no-code tools were having their moment. In 2025 France's CNIL issued 21 sanctions for cookie and tracker violations - the largest year yet - and the pattern across them is directly relevant to app builders: trackers firing before a choice, and refusal mechanisms that did not actually stop anything.
The headline cookie consent fines tell the story. SHEIN received EUR 150 million in September 2025, partly for a reject button that looked like it worked but left tracking running. Google received EUR 325 million the same month. And in November 2025 the CNIL fined American Express Carte France EUR 1.5 million for three separate failures: advertising cookies placed before any choice, cookies placed despite refusal, and cookies still being read after consent was withdrawn.
As of August 2026, the pace has not slowed - the CNIL has confirmed cookies remain a priority enforcement theme this year, and the UK's Information Commissioner's Office has been working through a review of the country's most-visited websites since early 2025. None of these decisions cared what tool built the site. A FlutterFlow app that sets _ga before consent fails in precisely the same way a hand-coded one does.
FlutterFlow Pitfalls to Check Before You Publish
A few problems come up repeatedly in FlutterFlow projects specifically. Each is cheap to fix before launch and expensive after.
Consent must survive navigation. A Flutter web app is a single-page app: routes change without a page reload, so the banner's decision has to persist in one consent state rather than being re-evaluated per URL. A banner that reappears on every route change usually signals broken state handling, not caution.
Custom widgets smuggle in trackers. A chat widget, map embed, or video player added through custom code brings its own cookies and storage. Run a cookie scanner against the published URL after every meaningful release, because your storage footprint changes whenever a custom widget does.
Progressive web app mode changes nothing legally. Enabling PWA installs a service worker and caches assets for offline use, which is fine - but the consent banner must still appear on first load, and cached pages do not excuse trackers that fire without a choice.
Mobile builds need their own consent path. The web banner does not travel to iOS or Android. Those builds rely on Apple's App Tracking Transparency prompt and Google's User Messaging Platform, so plan consent per platform even though the project is one codebase.
Different builders, same rules. If part of your product runs on Bubble.io or was generated in Firebase Studio, the consent obligations are identical - only the injection point for the banner differs.
Frequently Asked Questions
Does a FlutterFlow app on a flutterflow.app subdomain need a cookie banner?
Yes, if visitors in the EU or UK can reach it and it stores anything non-essential on their devices. The ePrivacy Directive applies based on who uses the app, not on whether you pay for a custom domain.
Can you add a cookie banner in FlutterFlow without exporting the code?
Yes. Paste your consent banner's script tag into the Custom Headers box under Settings and Integrations, then publish. FlutterFlow injects it into the head of the generated index.html, so no code export or Dart changes are needed.
Does Firebase Authentication need cookie consent?
Keeping a signed-in user's session in IndexedDB is generally strictly necessary and exempt from consent. Anything beyond that, such as analytics identifiers or preference storage that the user did not request, needs prior consent under Article 5(3) of the ePrivacy Directive.
Does FlutterFlow's Google Analytics integration set cookies before consent?
On web builds it can. The integration runs through Firebase Analytics, which uses gtag-based measurement and sets _ga cookies. Configure Google Consent Mode v2 with default denied states, or block the measurement script until the visitor accepts analytics.
Do mobile builds of the same FlutterFlow project need the web banner too?
No. A banner injected through Custom Headers only exists in the web build. iOS and Android builds handle consent through platform mechanisms such as Apple's App Tracking Transparency and Google's User Messaging Platform SDK.
Ship Your FlutterFlow App With Consent Sorted
If your FlutterFlow app is heading for European visitors, the banner belongs in Custom Headers before launch day, not after the first complaint. Kukie.io scans your published URL, categorises what it finds across cookies and local storage, and serves a banner that blocks non-essential scripts until visitors choose.
