Why does Google login work in preview but fail on my custom domain?
If Google shows redirect_uri_mismatch, compare the redirect_uri sent by the failing request with the authorized URI for that Google OAuth client. If Google accepts the login but the browser returns to the wrong app address, check the auth service’s app redirect settings instead. These are different hops.
Why this matters
A working preview does not prove the custom-domain sign-in works. Changing the wrong URL can leave the original fault in place. First identify whether your app uses managed Lovable Cloud authentication, your own Google credentials in Lovable Cloud, or an external Supabase project.
What we do not know yet
- Documentation reviewed on October 14, 2026. The procedure below is a proposed diagnostic workflow, not a live test of a customer app or a measured success rate.
- Without the failing request and auth configuration, this guide cannot identify your exact cause. A callback that succeeds followed by a missing session needs separate cookie, session-exchange or application debugging.
Diagnose the failing hop before changing settings
- Start sign-in from the failing custom domain. Record the visible error and the address where the flow stops. A login screen, successful deployment or HTTP 200 alone does not prove a user session exists.
- For redirect_uri_mismatch, inspect the authorization request in the browser network panel and compare only its redirect_uri with the registered Google callback. Match scheme, host, path and trailing slash. Do not share the full request URL, authorization code, tokens or state.
- Use the matching setup below. Keep the Google callback, the application return URL and the default Site URL separate. Do not replace every address with your homepage.
- If your deployed code builds a redirect from an environment variable, verify the value for the deployment you are testing and redeploy after correcting build-time configuration.
- After the change, use a fresh private browser session on the custom domain. Sign in, reload a protected page, perform one permitted account action, then sign out. Repeat on a preview if previews must remain supported.
Which settings belong to your stack?
Lovable Cloud with managed Google authentication
Lovable documents automatic auth URL updates when publishing or connecting a custom domain. A manually overridden Site URL remains unchanged. Check for that override before assuming a missing Google Console entry.
Managed Google authentication does not require your own Google OAuth client setup. Make sure you are debugging sign-in for users of your published app, not sign-in to your Lovable workspace.
Lovable Cloud with your own Google credentials
Open More → Cloud → Users → Auth settings → Google. Copy the exact redirect URL shown there into the authorized redirect URIs for your Google client, then select that redirect in Lovable and save. Do not invent a callback path from the custom domain.
An external Supabase project
Lovable does not automatically update an external Supabase project’s auth settings. For Google login, copy the callback from Supabase’s Google provider configuration into Google’s authorized redirect URIs. Google’s authorized JavaScript origins contain app origins; they are a separate field.
In Supabase Auth URL Configuration, Site URL is the fallback when no redirectTo is supplied. Set the intended production default. The app’s redirectTo must match an allowed Redirect URL. Use exact production paths; apply preview patterns only to the preview addresses you need.
If using Vercel previews, Supabase’s redirect guide shows a preview pattern and a production/preview URL helper. Follow those for app return URLs. Do not paste a Supabase wildcard into Google’s exact callback list.
A URL map to use while diagnosing
This is an illustrative configuration map, not a tested deployment. Copy actual values from your provider settings; the example addresses are placeholders.
External Supabase plus Google
| Setting | Illustrative value or source | Purpose |
|---|---|---|
| Google authorized redirect URI | Exact callback copied from Supabase’s Google provider panel | Google returns the response to the auth service |
| Supabase Redirect URLs and app redirectTo | https://app.example.com/auth/callback, if that route exists in your app | The auth service returns the user to the app |
| Supabase Site URL | https://app.example.com | Fallback return address when redirectTo is absent |
Related guides
Sources
Should I change my RLS policies to fix redirect_uri_mismatch?
No. Fix the callback mismatch first. Database permissions do not register a Google OAuth redirect URI. If login succeeds but loading data fails, investigate that as a separate authorization problem.
Does fixing the callback prove the app is ready to launch?
No. It proves only the retested sign-in flow works in that environment. Test session persistence and the account action you need, then continue the broader launch checks.
What if I use Auth.js, Clerk or another provider?
Find the callback URL generated by that integration and follow its provider-specific documentation. The Supabase callback map on this page does not apply to every auth library.