Lovable Google Login Not Working? Fix the localhost Redirect
Sign in with Google works on localhost but redirects to localhost:3000 on your Lovable preview or custom domain? It's almost always Supabase URL configuration — here's the fix.
You added "Sign in with Google." It works when you test locally. On your Lovable preview URL or custom domain, clicking the button sends you to localhost:3000 — or loops forever, or lands on a blank page.
This is the #1 auth problem I see in Lovable + Supabase apps. It's not your Google settings alone. Supabase is the middleman, and it's still pointing at the wrong place.
Why this happens
The OAuth flow goes: your app → Google → Supabase → back to your app. Supabase decides the final redirect using Site URL and Redirect URLs in the Auth settings. Lovable and local dev often leave these at http://localhost:3000. Google OAuth can succeed and Supabase still sends users to localhost.
Fix it in 10 minutes
1. Supabase → Authentication → URL Configuration
Update Site URL to your live URL — not localhost:
- Lovable preview:
https://preview-xxxxx.lovable.app(or your.lovable.devpreview) - Custom domain:
https://yourdomain.com - Production: whichever URL users actually open in the browser
Under Redirect URLs, add every URL users might land on after login:
https://preview-xxxxx.lovable.app/**
https://yourdomain.com/**
https://*.lovable.app/**
The /** wildcard matters — Supabase rejects redirects that aren't explicitly allowed.
2. Google Cloud Console → OAuth client
Under Authorized redirect URIs, you need Supabase's callback — not your app URL:
https://YOUR-PROJECT-REF.supabase.co/auth/v1/callback
Under Authorized JavaScript origins, add your app domains:
https://preview-xxxxx.lovable.app
https://yourdomain.com
Do not put localhost here for production testing unless you're still developing locally.
3. Lovable custom domain? Update everything again
Connecting a custom domain is a common trigger: auth "worked on the lovable.app URL" and breaks on your domain. Every time the public URL changes, repeat step 1 for the new domain. Also update Stripe webhooks and any OAuth provider if you added more than Google (production deploy checklist).
4. Test in an incognito window
Cached sessions hide redirect bugs. Open a private window, go to your production or preview URL (not localhost), and try Google sign-in once.
Still broken? Check these
| Symptom | Likely cause |
|---|---|
| Redirects to localhost | Site URL still localhost:3000 in Supabase |
| "redirect_uri_mismatch" | Google callback URI missing or wrong project ref |
| Infinite redirect loop | Site URL and Redirect URLs disagree; or http vs https mismatch |
| Login works but user is logged out on refresh | Cookie domain / session storage mismatch across subdomains |
| Works on preview, fails on custom domain | Custom domain not added to Supabase Redirect URLs |
Open browser DevTools → Network tab during login. The first failed redirect (302 to wrong host, or 400 from Supabase) tells you which layer is wrong.
When to stop prompting the AI
If you've updated Supabase and Google three times and it still redirects to localhost, the codebase may have a hardcoded redirectTo: 'http://localhost:3000' in the sign-in call. The AI will often "fix" OAuth by changing the wrong file and burning credits.
That's a $299 triage job: I trace the actual signInWithOAuth call, align every URL across Supabase, Google, and your deployed domain, and verify login holds in production — usually same day.
Stuck? I'll fix it for a fixed price.
I'm a senior full-stack engineer who audits, fixes, hardens, and deploys broken Lovable, Bolt, Cursor, v0, and Replit apps. Fixed price — diagnose before I touch a line of code, so you stop burning credits on prompts that make it worse.
Vibe-Code Rescue — from $299