Apps built on Lovable ship fast. A few prompts, a custom domain, and a working React frontend with Supabase auth is live within a single afternoon. What does not ship with the generated bundle: any form of cookie consent.
That gap matters once the app starts collecting visitors from the EU, UK, or other jurisdictions with prior-consent rules. Lovable generates a standard Vite + React project styled with Tailwind and shadcn/ui, with Supabase handling the backend. When Google Analytics, Meta Pixel, or PostHog gets added to that stack, those scripts fire on page load and set tracking cookies before the user has any chance to refuse.
Why Lovable Apps Need a Cookie Banner
The legal trigger is not whether the app was hand-coded or AI-generated. Under Article 5(3) of the ePrivacy Directive, storing or accessing information on a user's device requires prior, informed consent unless the cookie is strictly necessary for the requested service. The GDPR then governs how that consent is captured, recorded, and withdrawn.
Most Lovable apps include at least one category of non-essential cookies the moment a developer adds analytics. A typical setup pulls in:
_ga,_ga_*from Google Analytics 4ph_*from PostHog if the official integration is wired in_fbpfrom Meta Pixel when conversion tracking is addedSupabase auth cookies (essential, no consent needed) such as
sb-access-token
Only the Supabase auth cookies fall under the strict-necessity exemption. Every other entry on that list triggers prior consent obligations the second the page loads. Knowing which bucket each cookie falls into is the foundation of cookie categorisation.
Recent Enforcement Makes This Concrete
The CNIL issued 83 sanctions in 2025 worth approximately EUR 486.8 million, with cookies and advertising trackers driving most of that total. On 3 September 2025, the French regulator fined Google EUR 325 million and SHEIN EUR 150 million for cookie consent violations, with the SHEIN penalty being the largest cookie-related fine in CNIL history.
Two later decisions targeted smaller operators and confirmed that scale does not buy immunity from the rules. On 20 November 2025, the CNIL fined Conde Nast EUR 750,000 over cookies set without consent on vanityfair.fr. A week later, on 27 November 2025, American Express Carte France was fined EUR 1.5 million after inspectors found that advertising cookies fired before any choice, that cookies still appeared after refusal, and that cookies kept reading data after the user withdrew consent. A round-up of the biggest cookie fines from 2025 to 2026 covers the full picture.
A vibe-coded MVP with 200 weekly visitors is unlikely to attract a regulator's attention. A vibe-coded SaaS with 50,000 EU users absolutely can.
What a Compliant Banner Has to Do
A banner that simply displays a notice without blocking the cookies behind it does nothing useful. CNIL guidance and the 2025 American Express case make the technical bar clear:
| Requirement | What the banner has to do |
|---|---|
| Prior consent | Block analytics and marketing scripts from running until the visitor chooses |
| Symmetric choice | Reject button as prominent as the accept button, both visible on the first layer |
| Granular categories | Toggle controls for analytics, marketing, and preference cookies separately |
| Withdrawal | Persistent way to change or revoke consent, with cookies actually stopping when revoked |
| Audit trail | Timestamped logs of each choice for later proof |
Pre-ticked boxes, hidden refusal buttons, and "Accept All" highlighted while "Reject All" sits behind a "More options" link all count as dark patterns. The CNIL has repeatedly fined operators for exactly that layout.
Three Ways to Add a Banner to a Lovable App
Because Lovable produces a standard React + Vite project with full code access through GitHub, every banner technique that works for a hand-coded React SPA also works here. The differences come down to how much code lives in the Lovable workspace versus an external service.
Option 1: A Script Tag in index.html
The simplest approach. A consent management platform script is added to index.html in the <head>, the banner renders before React hydrates, and the platform handles script blocking, geo-detection, and consent logging. Lovable's chat agent can edit index.html directly with a prompt like "add the following script to the head of index.html". No npm install, no React component to maintain, and any future Lovable edits to the rest of the app leave the banner untouched.
This is the same approach covered in the React cookie consent guide, and it transfers cleanly because Lovable apps are React SPAs underneath.
Option 2: An npm Package
Packages like react-cookie-consent ship a component that renders inline. Prompt Lovable to install the package, drop the component into the root layout, and wire up handlers that initialise analytics only on accept. The downside: script blocking has to be implemented manually, which means analytics calls scattered across components need consent checks, regulatory updates require code changes, and any geo-detection has to be built from scratch.
Option 3: Google Tag Manager with Consent Mode
For apps already running multiple Google products, Google Tag Manager centralises tag loading. The banner sets Google Consent Mode v2 signals, GTM holds the analytics tags until consent arrives, and modelled conversions fill some of the gap from rejecting visitors. This setup needs a CMP that integrates with Consent Mode rather than just a static banner.
SPA-Specific Pitfalls
Lovable apps use React Router for navigation. Pages do not reload, so anything that depends on full page lifecycle events behaves differently from a classic multi-page site. A few things to watch:
Analytics initialisation that runs once on mount will not re-fire on route changes. The official PostHog Lovable integration sets capture_pageview: false and relies on the PostHogProvider to track route transitions automatically. GA4 needs a similar pattern with a custom router listener.
Consent state must survive route changes. Storing the choice in localStorage rather than React state keeps it persistent across navigations and reloads, and lets script gates check it without prop drilling.
Consent revocation must actually stop cookies. Setting a flag is not enough. Existing cookies need to be deleted from the document and from any subdomains, and scripts already loaded need to be torn down or instructed to stop tracking. The November 2025 American Express decision turned on exactly this point.
Verifying the Implementation
Open Chrome DevTools, clear all cookies and site data, then reload the published Lovable app in an incognito window. Before clicking anything on the banner, check the Application tab. If _ga, _fbp, or any other non-essential cookie appears, the banner is not actually gating scripts.
Click through three or four routes without making a choice. The cookie list should still show only essential cookies. Then accept, refuse, and revoke in sequence, checking after each step that cookies appear or disappear as expected. Conditional script loading covers the common patterns for getting this right.
A free cookie scan picks up cookies the developer console missed, including ones set by third-party iframes or fonts. Scheduled rescans catch the regression that happens when a future Lovable prompt adds a new tracking script and no one notices.
Frequently Asked Questions
Does a Lovable app need a cookie banner if it does not use Google Analytics?
If the app sets any non-essential cookie, yes. Embedded YouTube, social share widgets, A/B testing scripts, and some Supabase analytics features can set cookies that require consent under the GDPR and ePrivacy Directive.
Can the consent banner be added through a Lovable prompt?
Yes. Lovable can edit index.html and install npm packages on request. Prompting the agent to insert a CMP script tag in the head of index.html is the fastest path, since the banner then sits outside the React tree and survives future regenerations.
Are Supabase auth cookies subject to consent rules?
No. Supabase session cookies such as sb-access-token are strictly necessary for authenticated functionality and fall under the ePrivacy Directive's exemption for cookies required to deliver a service the user explicitly requested.
What happens to analytics data when visitors refuse cookies?
Without cookies, GA4 and similar tools cannot identify returning users or build cross-session profiles. Google Consent Mode v2 sends anonymous, cookieless pings on refusal, and Google's modelling fills some of the gap on aggregate metrics.
Does the banner need to appear on the Lovable preview domain too?
If the preview domain is publicly accessible and visitors from regulated jurisdictions can reach it, then yes. The safer pattern is to add the banner once and let it run on every environment.
Can the same banner cover the Lovable app and a separate marketing site?
It can if both sites share a parent domain and the CMP supports cross-subdomain consent. Different root domains require separate consent capture, though some platforms offer linked workspaces to keep configuration in sync.
Add a Compliant Banner to Your Lovable App
Vibe coding gets the app shipped. Consent management keeps it shipped without a regulator letter landing in the inbox six months later. Kukie.io scans Lovable apps for cookies, generates a banner script that drops into index.html with one prompt, blocks analytics and marketing scripts until the visitor chooses, and logs every consent decision for audit purposes.
