Martin Macek

Remove the Edit with Lovable badge, free or paid

The badge comes off on any paid plan. Open Project settings → Publishing and turn on Hide Lovable badge. It is a per-project setting and it applies to your live site immediately - no republish. The cheapest plan that has the toggle is Pro at $25/month, or $250 billed annually (checked August 2026). On Free the toggle isn't there.

That's the answer if you're staying on Lovable, and for a lot of people it's the right one. There is also a free route, and it isn't a CSS hack.

But there's a second fact nobody mentions, and it changes the decision: the badge is not in your code. It isn't in your repo, it isn't in your build output, and it doesn't survive leaving Lovable's servers. I checked, and below is how you can check your own project in about a minute.

What the badge actually is

Fetch the HTML of any Lovable-hosted site that still has the badge and you find this, sitting after your app's mount point:

served HTML, your-project.lovable.app
<body>
  <div id="root"></div>

<aside
  id="lovable-badge"
  role="complementary"
  aria-label="Edit with Lovable">
  <a id="lovable-badge-cta"
     href="https://lovable.dev/projects/lovp_…?utm_source=lovable-badge"
     rel="noopener nofollow">
    <span id="lovable-badge-text">Edit with</span>
    <svg …>…</svg>
  </a>
  <span id="lovable-badge-divider" aria-hidden="true"></span>
  <button id="lovable-badge-close" aria-label="Dismiss">…</button>
</aside>

Three things worth pulling out of that.

It is served, not built. The <aside> arrives after <div id="root"></div>, along with a <style> block Lovable injects into your <head> - one that sets background-color, color and box-shadow with !important and pins the badge at z-index: 1000000. Your React app never renders it. It is bolted onto the response on the way out.

There is a dismiss button. #lovable-badge-close is real, and a visitor can click the × and make the badge go away. It is not persisted anywhere - an inline script just sets display: none - so it comes back on the next page load. Useful for exactly one situation: you're screen-sharing a demo right now and want it gone for the next ten minutes.

The badge is not in your repository

Here's the part that decides whether you need to pay.

Lovable's Git sync is available on every plan, including Free. Connect it and you get a repository containing your actual source. I pulled the index.html from two publicly visible Lovable-synced repos and compared them against their live pages. Neither repo contains a single occurrence of lovable-badge. The badge only exists in the served response.

You can run the same check on your own project in one command, from your repo root:

your repo — expect zero results
grep -ri "lovable-badge" . --exclude-dir=node_modules

Then compare against the live site:

your live site — expect 1
curl -s https://your-project.lovable.app/ | grep -c 'id="lovable-badge"'

Same project, two different answers - because the badge is a property of Lovable's hosting, not of your application.

The consequence is straightforward: build that repository and host the output somewhere else, and there is no badge to remove. Nothing to hide, nothing to toggle, nothing to pay for. And this is not a workaround anyone has to feel clever about - Lovable's own documentation says it plainly: "You can clone your repository, modify it outside Lovable, deploy it on your own infrastructure, or fully self-host without restriction." Lovable's terms carry no attribution requirement, and the docs state you own the code. Leaving with your source is the supported path, not the loophole.

What does follow your code out

Not everything Lovable-shaped disappears. Older projects carry this in the committed index.html:

index.html, older Lovable projects
<!-- IMPORTANT: DO NOT REMOVE THIS SCRIPT TAG OR THIS VERY COMMENT! -->
<script src="https://cdn.gpteng.co/gptengineer.js" type="module"></script>

That is the editor bridge - the thing that lets Lovable's visual "select an element and describe a change" mode talk to your running app. The warning is aimed at people still editing inside Lovable, where deleting it breaks the editor. On a build you're hosting yourself it does nothing except load a third-party script from cdn.gpteng.co on every page view. Newer projects don't include it; the second repo I checked has no gpteng reference at all.

The other leftovers are metadata, and they're the reason a site can still read as AI-generated to anyone viewing source:

index.html, default Lovable metadata
<meta name="description" content="Lovable Generated Project" />
<meta name="author" content="Lovable" />
<meta name="twitter:site" content="@Lovable" />

That first one is your search-results snippet. Fix it whether or not you ever move hosts.

One thing that does not come off with the badge, if you stay: the six Lovable-hosted custom-domain sites I checked all had clean, badge-free HTML - and every one of them still received an injected <script defer src="/~flock.js"> analytics tag. Hiding the badge removes Lovable's branding from your page. It does not remove Lovable from your page.

The downgrade trap

If you pay for Pro, hide the badge, and later drop back to Free, read this twice, because it is the part that catches people.

Your live site keeps the badge hidden. Nothing changes - until your next publish. At that publish the badge returns and Lovable switches the Hide Lovable badge setting off in Project settings → Publishing. So it isn't a case of the badge quietly reappearing; the preference that was holding it back is gone too, and if you re-subscribe later you have to go and turn it on again.

The practical version: a downgrade is safe until you touch the site. The day you ship a copy change six weeks later is the day the badge comes back, and it will not be obvious that publishing is what did it.

Worth knowing too: on Lovable the badge and the custom domain are the same purchase. Custom domains are paid-plan-only, so you cannot end up on Free with your own domain and a badge. Once you're paying for a domain, the badge toggle is already included - the full custom-domain walkthrough is here. That is not true everywhere. On Replit, for instance, custom domains carry no plan gate at all and the badge is the thing you're buying - the sourced table for all seven builders shows which ones split the two purchases and which bundle them.

If your build's final destination is WordPress hosting you're already paying for, Parkstatic is the piece that puts it there: a GitHub Action builds the synced repo, pre-renders the routes, and hands the output to a WordPress plugin that serves it from your existing domain. The badge never enters the picture, because Lovable's edge is no longer serving the page. It's $29.99/year or $89.99 once (checked August 2026) against $250 a year for Pro - the full cost comparison is here.

About the CSS trick

There is a widely shared workaround that tells you to prompt Lovable into adding #lovable-badge { display: none !important; } to your stylesheet. I'm not going to write the guide for it, for two reasons that have nothing to do with being precious.

The first is that it's a paid feature, and you'd be using Lovable's free hosting while switching off the one thing they ask for in return. If you don't want to pay for the badge removal, the honest move is the one above: take your code and host it yourself. Lovable explicitly permits that.

The second is that it doesn't hold. The badge markup and its styles are injected outside your application by a system you don't control, and the injected <style> block already uses !important on the properties that matter. Any CSS you ship is fighting a moving target - one selector rename on Lovable's side and the badge is back on a client site you stopped looking at months ago. Compare that with a build hosted elsewhere, where the badge is not absent because you hid it, but because it was never generated.

When paying Lovable is the right call

Three cases, and I'd rather you recognised yourself in one of them than wasted a weekend.

If your project was created on or after 13 May 2026, check before you plan an exit. Lovable changed what it generates on that date: new projects are server-side rendered on TanStack Start, where older ones were React + Vite single-page apps that build to a folder of static files. An SSR project needs something running at request time. Static hosting only works for sites that are actually static - so if yours renders per request and you're not willing to reconfigure it to pre-render, Parkstatic is the wrong tool and so is every other static host. Pay Lovable, or move to a host that runs Node.

If your app uses Lovable Cloud - a database, auth, file storage, AI features - moving the front end moves none of that. You'd pay twice and own a split system.

If you have one site, one badge, and no interest in Git, $25 for one month is cheaper than an afternoon of your time. Toggle it, ship the client work, cancel if you want - just remember what happens at the next publish.

If none of those describe you, the badge isn't a paywall you need to get around. It's a hosting artifact, and it disappears when the hosting does. The deploy guides cover getting a build out of each builder and onto a domain you already own.