Lovable Google login not working: the fixes

As of October 10, 2026, when Sign in with Google fails in a Lovable app, the cause is almost always a setting, not the code. Either the address people return to after Google is not on an approved list, which shows up as redirect_uri_mismatch or as sign-in that works in the preview but not on your published site. Or the Google project behind the login is still in Testing, so only the test users you listed can get in. Or the consent screen shows a supabase.co address because the app's brand is not verified with Google. On Lovable Cloud, the simplest fix is often Lovable's managed Google sign-in, which needs no Google Cloud setup. With your own credentials, add every live address in Google Cloud and in your auth settings, publish the app in Google, and verify your brand.

This guide is for founders whose customers cannot sign in with Google. It goes symptom by symptom: what you see, why it happens and where to click in Lovable, Supabase and Google Cloud. Platform facts come from the Lovable, Supabase and Google documentation listed under Sources. To add Google sign-in in the first place, see our guide to Lovable authentication and user roles.

How does Google sign-in work in a Lovable app?

When someone clicks Sign in with Google, your app sends them to Google with a return address. Google checks that address against a list you approved, asks the person to agree, and sends them back. On a Supabase backend there are two hops: Google returns them to your Supabase project's callback address, then Supabase sends them on to your app, but only to addresses on its own list. The standard behind this is OAuth. It proves who someone is; deciding what they may do is a separate job, explained in authentication vs authorization.

Which settings matter depends on how your app was set up. Lovable's documentation describes three routes:

How do you find which problem you have?

1. 01Reproduce it as a customerOpen your published address in a private window and sign in with a Google account that is not yours as the developer. Write down the exact error and the address in the browser bar.
2. 02Match the errorredirect_uri_mismatch means a return address is missing. Being refused unless you are a listed tester points to Testing mode. org_internal means the app is limited to your own organization. A supabase.co address on Google's screen is a branding issue. disallowed_useragent means the link opened inside another app's built-in browser.
3. 03Check your auth settingsOn Lovable Cloud, open More, then Cloud, then Users, then Auth settings. Note whether Google is managed or uses your own credentials, which redirect URLs are selected, and under Advanced, the Site URL and Redirect URLs. On your own Supabase project, open Authentication, then URL Configuration.
4. 04Check Google CloudWith your own credentials, open the Google Auth Platform in Google Cloud Console. Audience shows publishing status, user type and test users. Clients holds the redirect URIs. Data Access lists the scopes. Branding holds the name, logo and verification.
5. 05Read the auth logsOn Lovable Cloud, open More, then Cloud, then Logs, and choose the authentication logs. On your own Supabase project, open Logs and select Auth.

Why does Google sign-in work in the preview but not on my published site?

Because the published address or your custom domain is not on the list of places sign-in may return to. Lovable's own troubleshooting says the same: when sign-in works in the preview but fails on the published app or a custom domain, the issue is usually redirect URLs. The fix depends on your route:

• Lovable Cloud, managed: when you publish, Lovable sets the Site URL to your lovable.app address, and it adds a custom domain to the redirect URLs once the domain is Live. A Site URL you set yourself stays unchanged. If sign-in still fails, ask Lovable in the project chat to update the redirect URLs for your domain.
• Lovable Cloud, your own credentials: when you connect a domain, Lovable adds its redirect URL to the list but does not select it. Add that URL as an Authorized redirect URI in Google Cloud, select it in Lovable and click Save. Until then, Lovable says sign-in fails on the new domain with a redirect URI mismatch.
• Your own Supabase project: Lovable's documentation says you add the domain in your Supabase project's auth settings yourself. In Authentication, URL Configuration, set the Site URL, which is where people land when the code names no destination, and add each live address to Redirect URLs.

Two details catch people. Supabase's Site URL starts as http://localhost:3000, and Supabase says to change it to your production address; a customer landing on localhost is the giveaway. And Lovable sends www.yourdomain.com to yourdomain.com by default, so approve the address customers actually end up on.

What does redirect_uri_mismatch mean and how do you fix it?

Google's definition: the return address in the sign-in request does not match an authorized redirect URI for your OAuth client. Google requires an exact match, including the scheme, letter case and trailing slash. Addresses must use https, except localhost, and cannot contain wildcards or raw IP addresses.

To fix it, open Google Cloud Console, then Google Auth Platform, then Clients, choose your Web application client and edit Authorized redirect URIs. What belongs there depends on your route. On Lovable Cloud with your own credentials, add the addresses Lovable lists. On your own Supabase project, add your Supabase callback address, which Supabase shows on its Google provider page; your app's own address goes under Authorized JavaScript origins and in Supabase's Redirect URLs, not here. Google warns that changes may take 5 minutes to a few hours to take effect, so wait before deciding a fix failed.

Two related checks: Lovable says only a Web application client works with its redirect flow, and Google's invalid_client error means the client secret is wrong.

Why does Google sign-in work for me but not for my customers?

Usually because the Google project is still in Testing. Google limits a project in Testing to up to 100 test users listed on its consent screen. Lovable's troubleshooting tells you to add your own account as a test user while the app is not published, which is often why it works for you. To open it to everyone, go to Google Auth Platform, then Audience, and click Publish app. Google says an app In production is available to any user with a Google Account.

Check the user type on the same page. Internal limits sign-in to members of your Google Cloud organization, and everyone else gets an org_internal error. A customer-facing app needs External. Two other errors come from the customer's side. admin_policy_enforced means their company's Google Workspace administrator blocks the request. disallowed_useragent means they opened your link inside another app's built-in browser, which Google refuses; ask them to open it in Safari or Chrome.

Does publishing mean Google must verify your app? Google's verification help page says an app using only non-sensitive scopes need not complete app verification, but needs a lighter brand verification to show its name and logo. Google's Auth Platform overview words this more strictly, saying all production apps must complete verification. Sign-in only needs email and basic profile, which Google pre-fills as non-sensitive, so plan for brand verification.

Why does Google's screen show supabase.co or say it hasn't verified this app?

These are two different problems. The first is branding. Google shows only your application's domain on the consent screen until your brand is verified. On your own Supabase project, the domain Google sees is your Supabase project's, so customers see an address like abcd.supabase.co. Supabase notes that this reduces trust and raises the risk of phishing. There are three ways out:

• On Lovable Cloud, use managed sign-in. Lovable's documentation says its consent screen shows your application name.
• Verify your brand in Google Auth Platform, then Branding. Google requires your authorized domains to be verified in Google Search Console, a public homepage, and a privacy policy on the same domain, linked from the consent screen. The automated check often takes minutes; a manual review usually takes 2 to 3 business days.
• Give Supabase a custom domain such as auth.yourdomain.com. Supabase offers this as a paid add-on for projects on a paid plan. Add the new callback address in Google in addition to the supabase.co one, which keeps working.

The second is the unverified app warning. Google shows it when an app requests sensitive or restricted scopes without verification, and such an app is capped at 100 new users after the warning first appears. Plain sign-in should not trigger it. If your customers see it, the app is asking for more than sign-in, such as access to their calendar or files. Remove the extra scopes under Data Access, or submit the app for verification, which Supabase warns may take a long time. Lovable's managed mode requests only email and basic profile; custom scopes need your own credentials.

Why does login loop back to the sign-in page?

A loop has two common causes. Settings: Google sends the person back to a different address from where they started, such as your lovable.app address or localhost instead of your custom domain. Code: a page decides the person is signed out before the sign-in has finished loading, and sends them back to log in. Watch the browser bar after choosing a Google account. If the address changes, fix the settings above. If it stays the same and you bounce, it is the code.

For the code case, this prompt is a good start: "Google sign-in loops back to the login page on [your domain]. Make the sign-in send users back to the address they started on, wait for the session to load before any page treats the user as signed out, then go to [page]. Do not change other pages." The return address must still be on your approved lists.

Know what prompting can reach. On Lovable Cloud, Lovable can change your app's auth settings from the chat. On your own Supabase project it cannot; Lovable's docs point you to the Supabase dashboard. No prompt changes your Google Cloud project: redirect URIs, publishing status and branding are yours to set.

When should you stop prompting and get help?

Most of these fixes take minutes once you know the cause. Get an engineer when:

• Customers are locked out right now and you are losing sign-ups or paying users.
• You switched credentials, domains or backends and existing users cannot get back into their accounts.
• Your app needs Google data beyond sign-in, which brings verification, a privacy policy and a review.
• The same sign-in fix has failed three times.
• You are not sure what role a new Google user gets. Sign-in proves who someone is, not what they may see, and a wrong default exposes data. See when users can see each other's data.

Our vibe-coding rescue service takes on exactly this: find the fault, fix it, and test sign-in on every live address. For a wider view of your app first, the free production-readiness check scores it and names its biggest risks. Ongoing plans, with code review and security checks on every change, are on our pricing page.

Sources

All checked on October 10, 2026.

• Lovable documentation: Add Google authentication to your app, on managed and own credentials, redirect URIs, custom domains and troubleshooting (docs.lovable.dev/features/google-auth).
• Lovable documentation: Users and authentication, on Site URL, redirect URLs and sign-in that fails after publishing (docs.lovable.dev/features/authentication).
• Lovable documentation: Set up a custom domain, on auth redirect URLs and the www redirect (docs.lovable.dev/features/custom-domain).
• Lovable documentation: Connect to Supabase, on configuring social logins in the Supabase dashboard (docs.lovable.dev/integrations/supabase).
• Lovable documentation: Logs, on authentication logs (docs.lovable.dev/features/logs).
• Supabase documentation: Login with Google, on the callback URL, scopes, the supabase.co consent screen and verification (supabase.com/docs/guides/auth/social-login/auth-google).
• Supabase documentation: Redirect URLs, on the Site URL and allow list (supabase.com/docs/guides/auth/redirect-urls).
• Supabase documentation: Custom domains, on the paid add-on and OAuth callbacks (supabase.com/docs/guides/platform/custom-domains).
• Supabase documentation: Logs, on auth logs (supabase.com/docs/guides/telemetry/logs).
• Google: Using OAuth 2.0 for web server applications, on redirect_uri_mismatch and other authorization errors (developers.google.com/identity/protocols/oauth2/web-server).
• Google Cloud Help: Manage OAuth Clients, on redirect URI rules, propagation time and client secrets (support.google.com/cloud/answer/15549257).
• Google Cloud Help: Manage App Audience, on Testing, In production, test users and user types (support.google.com/cloud/answer/15549945).
• Google Cloud Help: Manage OAuth App Branding, on what users see before brand verification (support.google.com/cloud/answer/15549049).
• Google: Submit for brand verification, on requirements and timing (developers.google.com/identity/protocols/oauth2/production-readiness/brand-verification).
• Google Cloud Help: OAuth App Verification, Unverified apps, and Get started with the Google Auth Platform, on scopes, verification and the 100-user cap (support.google.com/cloud/answer/13463073; support.google.com/cloud/answer/7454865; support.google.com/cloud/answer/15544987).