Lovable Error 400: redirect_uri_mismatch After Publish

Google lets the user choose an account, but the published app never gets the user back. Instead, the browser stops at Error 400: redirect_uri_mismatch. This is one of the useful OAuth errors: Google received a callback URL that is not registered for the OAuth client. Capture that URL and compare it character for character before changing the login code.

Every platform claim below was checked against Google, Lovable and Supabase vendor documentation on 2026-10-09. App Rescue Desk is independent and is not affiliated with Google, Lovable or Supabase.

TL;DR

• redirect_uri_mismatch means the callback URL in the Google request does not match an authorized redirect URI for that client.
• Copy the callback URL Google received. Do not reconstruct it from memory.
• In a Supabase-backed Lovable app, Google usually returns to the Supabase Auth callback before Supabase returns the user to the app.
• Google Authorized redirect URIs and Supabase Redirect URLs are different lists with different jobs.
• If the exact URLs match but production still cannot create a session, stop editing allowlists and investigate the callback flow.

Why does a published Lovable app show redirect_uri_mismatch?

Google requires the request’s redirect_uri to match an authorized redirect URI exactly. The scheme, domain, path, case and trailing slash all count (Google OpenID Connect reference).

The error often appears after a production change rather than during the first build. Common triggers include:

• connecting a custom domain;
• replacing the Google OAuth client;
• moving the app to another Supabase project;
• changing the authentication callback route;
• publishing credentials from a different environment.

The sign-in button can remain unchanged while one of those addresses changes. That is why rewriting the button is a poor first response.

Which redirect URL should Google contain?

Separate these three settings:

For a connected Supabase project, the Google Authorized redirect URI is normally the Supabase callback shown on the Google provider page:

https://<project-ref>.supabase.co/auth/v1/callback

Do not replace it with the app’s dashboard URL. Supabase documents the callback URL under Google provider setup and lists the app origin separately (Supabase Google sign-in setup).

Lovable Cloud can provide the redirect URIs that must be added to Google. After you authorize those addresses in Google, Lovable asks you to select the matching entries in the project (Lovable Google authentication). Use the address shown for the production project, not one copied from another project.

What is one redirect_uri_mismatch fix you can try?

Use this fix only when Google’s error details show a callback missing from the selected OAuth client.

1. Copy the complete redirect_uri from the failed Google request.
2. Open the Google Auth Platform.
3. Open the Web OAuth client used by production.
4. Find Authorized redirect URIs.
5. Add the copied callback URL exactly.
6. Save the client.
7. Test Google sign-in on the published domain.

Do not add a wildcard. Do not add only the custom-domain home page. The entry must match the callback Google received.

Example:

Requested by production:
https://abccompany.supabase.co/auth/v1/callback

Registered in Google:
https://oldproject.supabase.co/auth/v1/callback

The concrete fix is to authorize the abccompany callback on the OAuth client that production actually uses. Keep the old callback only if another active environment still needs it.

After the change, complete one sign-in on the published domain. Confirm that the browser returns to the intended page and that the app has a session. Removing the Google error is not enough if the user returns logged out.

What if the URLs already match?

Do not keep adding variations. Check which symptom replaces the Google error.

Google reports origin_mismatch

origin_mismatch concerns the site that started the request. Compare the published origin with Authorized JavaScript origins. Do not add a path to an origin.

Google succeeds but Supabase returns to localhost or preview

Check Supabase Site URL, the additional Redirect URLs, and the redirectTo value used by the application. Supabase requires redirectTo to match its redirect allowlist and recommends an exact production URL (Supabase Redirect URLs).

The callback loads but the user returns logged out

The redirect mismatch is no longer the active error. If the callback returns the user but the app loses the session or logs them out later, use the Lovable JWT expired and invalid refresh-token diagnosis. If the callback page instead throws Application error: a client-side exception has occurred, use the client-side exception after deploy diagnosis. Neither failure is corrected by adding more OAuth URLs.

Supabase returns 401 Invalid API key

The Google callback mismatch is no longer the active error. A 401 Invalid API key response points to the Supabase project URL and key used by the published build. Follow the Lovable Supabase Invalid API key check before changing OAuth settings again.

Google login stopped for every Lovable project

Check the Lovable and Google service status before changing production credentials. A provider incident and one project’s URL mismatch need different responses.

What evidence should you keep?

Save a short, redacted record:

GOOGLE LOGIN FAILURE

1. Published app URL:
2. Timestamp and timezone:
3. Google error code:
4. redirect_uri received by Google:
5. OAuth client ID suffix:
6. Supabase project reference or Lovable Cloud project:
7. Last successful sign-in:
8. Domain, project or credential changes since then:

Do not include the OAuth client secret, access token, refresh token or user data. The client ID is not a secret, but the final few characters are enough to distinguish two configured clients in an incident note.

Frequently asked questions

Is redirect_uri_mismatch a Lovable platform outage?

The error itself identifies an OAuth client configuration mismatch. A platform incident can also stop social login, but it does not make an unregistered callback valid. Compare the exact URL first, then check provider status if many unrelated projects fail together.

Why does Google login work in preview but fail after publish?

Preview and production use different origins. They can also use different callback settings or OAuth clients. A successful preview test proves only that the preview path is authorized.

Should I add my custom domain as the Google redirect URI?

Add the custom-domain origin under Authorized JavaScript origins when it starts the sign-in. For Supabase Auth, Google normally needs the Supabase callback under Authorized redirect URIs. Use the exact callback displayed by the active authentication project.

Can I solve this by rebuilding Google login in Lovable?

Not when the requested callback is absent from the correct OAuth client. Authorize the exact callback first. Rebuild code only when the Google error has cleared and evidence identifies a separate callback or session defect.

When is this more than one URL change?

This article settles an exact Google callback mismatch. It does not repair an incorrect production client, a second Supabase project, a broken callback route or a session that disappears after Google returns.

If the registered callback matches but customers still cannot sign in, the Lovable authentication bug-fixing service → can trace the published flow across Google, Lovable, Supabase and the application callback. We agree the scope and price before anything in production changes.