Lovable cookie banner: what yours has to block, and a five-minute test that proves it does

The short answer

Lovable does not put a cookie banner on your app. If the app loads Google Analytics, the Meta pixel, Hotjar, a YouTube embed or anything else that stores or reads data in a visitor’s browser for a purpose other than making the app work, people in the EU, the UK and Switzerland have to agree first.

A banner that meets that bar does four things. It holds every non-essential script until a choice is made. It offers Reject as easily as Accept. It keeps a record of each choice. And it tells Google’s tags what was decided. A banner written by the Lovable agent does none of the four, for a structural reason this article explains. A consent tool that loads as the first script in index.html can do all four.

Does Lovable add a cookie banner?

No. On 23 September 2026 neither the Lovable editor nor Lovable hosting adds a consent banner to a published app, and the documentation does not describe one. What does arrive, by default or by prompt, are the things a banner exists to control.

• Lovable visitor analytics. It is on by default as soon as you publish. Lovable says it tracks visitors, page views, bounce rate, visit duration, traffic sources and devices, that it “measures overall traffic, not individual people”, and that it does not follow visitors across separate visits. The documentation does not say what, if anything, it stores in the visitor’s browser. You switch it off under Project settings, General, Publishing.
• Whatever you prompted for. “Add Google Analytics” puts the GA4 snippet in the head of index.html. “Add the Meta pixel” does the same for Facebook. TikTok, LinkedIn, Clarity, Hotjar and PostHog arrive the same way, and all of them run the moment the page loads.
• Embeds. A YouTube video, a Google Map or a Calendly widget inside a component sets third-party cookies the moment its iframe loads.

One more thing arrives if you use Lovable Cloud, which is built on Supabase: the login session. It lives in the browser’s local storage, and for an app people sign in to it is strictly necessary. It needs no consent, but it belongs in your cookie declaration.

Does your Lovable app need one?

The rule is not about cookies as such. Article 5(3) of the ePrivacy Directive, Section 25 of the German TDDDG and Regulation 6 of the UK’s PECR all cover storing or reading anything on a visitor’s device, which includes local storage and tracking pixels. The EDPB spelled that out in its 2023 guidelines on the technical scope of the rule. Consent is needed unless the storage is strictly necessary for something the visitor asked for, such as staying logged in or keeping a basket. The rule applies to visitors in those countries, wherever your company is based.

Why a banner built by prompt cannot block

Ask Lovable to “add a GDPR cookie banner” and you get a good-looking React component with an Accept button that writes a flag to local storage. It looks finished. The problem is when it runs.

A Lovable project is a Vite and React app. The browser reads index.html top to bottom and runs every script in its head straight away. Only then does it download the app bundle, start React and render your components. A banner component is one of those components, so by the time it asks its question, Google Analytics has already sent a page view and set _ga, and the Meta pixel has already set _fbp.

You can ask the agent to move the trackers into the component and start them only after Accept. That fixes the timing for those scripts, and leaves four gaps.

• Everything else still runs. Embeds, npm packages that start their own tracking and scripts added by the next prompt are not covered.
• No record. A flag in local storage proves nothing to a regulator. Under Article 7(1) GDPR you have to be able to show that consent was given.
• No signals for Google. Google Ads and GA4 expect Consent Mode v2 signals from visitors in the EEA and the UK. A homemade flag sends none.
• It drifts. The agent rewrites components as you prompt. A later change to the layout can quietly drop the gate, and nothing tells you.

What a Lovable cookie banner has to do

This is the list a regulator or an auditor works through, applied to a Lovable app.

1. Load first. The consent script is the first element inside <head> of index.html, above every other script. That is also the file Lovable prompts almost never rewrite.
2. Block by default. Analytics, marketing scripts, pixels and iframes stay off until their category is granted, including after the app changes route without a page reload. When the CNIL fined SHEIN €150 million in September 2025, a central finding was that cookies kept being written after visitors clicked Reject all.
3. Reject on the first layer. Reject all sits next to Accept all, at the same size and weight. The EDPB treats anything else as a deceptive design pattern. In its €325 million Google decision of September 2025, the CNIL counted six clicks to refuse against two to accept and found that consent was not freely given.
4. No pre-ticked boxes. Every optional category starts switched off.
5. Easy to change your mind. A permanent link or button reopens the banner, because withdrawing consent must be as easy as giving it under Article 7(3).
6. Proof. Every choice is recorded with the time, the banner version the visitor saw and the categories chosen.
7. Consent Mode v2. Google’s seven signals are set to denied before any Google tag runs and updated the moment the visitor decides.
8. A declaration that matches reality. The cookie list in your privacy policy names what the app really sets, and changes when the app changes.

Three ways to get one

A prompt-built component is fine for a prototype nobody outside your team visits. As soon as the link goes public with analytics on it, it is the risky option, because it looks compliant and is not.

A traditional consent platform works if you paste its script as the first element of the head and configure the categories in its dashboard. Check how it prices, since many charge per domain or by traffic, and check that it rescans, since a Lovable app changes with every prompt.

CookieCrumbs was built for this workflow. One prompt puts the tag at the top of index.html and marks your existing trackers, the scanner loads the published app in a real browser to find what it really sets, and scheduled rescans catch the pixel the next prompt adds. The step-by-step guide has the exact prompt. One honest limit: CookieCrumbs is not yet a Google-certified CMP and does not emit IAB TCF strings, so if your app shows AdSense or Ad Manager ads, pick a certified platform for now.

Test your Lovable cookie banner in five minutes

Whatever you install, check it yourself before you share the link. You need a browser and its developer tools.

1. Use the published URL. Open your-app.lovable.app or your own domain in a private window. The preview URL runs a different build and proves nothing about the live one.
2. Watch the network before you click. Open DevTools, go to Network, and filter for google, facebook, tiktok, clarity and hotjar. Reload. Nothing should load from those hosts while the banner is waiting. If you run Google Consent Mode in advanced mode on purpose, you may see Google requests carrying gcs=G100, which means consent is denied and no cookie is used.
3. Check storage. Under Application, look at Cookies and Local storage. There should be no _ga, _fbp, _clck or _hj entries yet.
4. Reject, then move around. Click Reject all, then open two other pages of the app. Still nothing from the tracking hosts, still no tracking cookies. This catches banners that only work on the first page.
5. Reload. The banner should not come back, and the link to reopen it should work.
6. Accept one category. In a fresh private window, allow analytics only. GA4 may now load. The Meta pixel may not.

If you would rather not click through it, the free scan reads your homepage and lists the trackers it finds, with no account needed.

Five common mistakes on Lovable apps

• Testing only the preview. The preview and the published app are separate builds with separate URLs. Test the one visitors see.
• Putting the consent script in App.tsx. Anything inside React runs too late. The tag belongs in index.html.
• Forgetting Lovable’s own analytics. It is on by default and sits outside your code, so no banner can hold it back. Check what it does or switch it off.
• Letting the agent fix the banner. When a consent tool is installed and the agent then “improves” it by writing its own component, you end up with two banners and one that blocks nothing. Reject that diff.
• Missing the embeds. A YouTube video on the landing page sets cookies before anyone clicks play. It needs the same treatment as a pixel.

FAQ

Does Lovable have a built-in cookie banner?

No. Lovable publishes apps without a consent banner, and its documentation does not describe one. You add one yourself, either by prompt, by pasting a consent tool’s script into index.html, or through a coding agent.

Can I just ask Lovable to build a GDPR cookie banner?

You can, and you will get a banner that looks right. It will not block anything that loads from index.html, because it renders after those scripts have already run, and it keeps no record of consent. Use it for a prototype, not for a public app with analytics.

Does a Lovable app with only a login need a cookie banner?

Usually not. The Lovable Cloud session that keeps people signed in is strictly necessary, so it needs no consent. You still need a privacy policy, and the moment you add analytics, pixels or embeds, you need a banner.

Is Lovable’s built-in visitor analytics allowed without consent?

Lovable says it measures aggregate traffic and does not follow visitors across visits, but it does not document what it stores in the browser. Whether it needs consent depends on that. Scan your published app to see, or switch it off under Project settings, General, Publishing.

Where does the cookie banner script go in a Lovable project?

As the very first element inside <head> in index.html, above every other script. Not in a component, not in a layout, not in a useEffect.

Will the banner survive when I keep prompting?

The tag in index.html almost always does, because prompts rewrite the src folder, not that file. What the next prompt can do is add a new tracker. A consent tool that rescans the published app catches that, and a homemade banner does not.

Sources

1. Lovable documentation, “Project analytics”, read 23 September 2026
2. Lovable documentation, “Lovable Cloud”, read 23 September 2026
3. Directive 2002/58/EC (ePrivacy Directive), Article 5(3)
4. EDPB, Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive
5. EDPB, Guidelines 03/2022 on deceptive design patterns, adopted 14 March 2022
6. CNIL, “Cookies placed without consent: SHEIN fined 150 million euros”, 3 September 2025
7. GDPR, Article 7, conditions for consent
8. Google, “Consent mode on websites and mobile apps”, Tag Platform documentation

Written by the CookieCrumbs team, published 23 September 2026. This is not legal advice. Facts carry their dates; if one has moved on, tell us and we will correct it.