Google sign-in shows "Error 400: redirect_uri_mismatch" with Supabase. How do I fix it?

• A user clicks “Sign in with Google” and lands on a Google page that says Error 400: redirect_uri_mismatch (“Access blocked” or “You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy”).
• It works in the Lovable or Bolt preview, or on localhost, but not on your live domain.
• It worked until you added a custom domain, switched to a new Google Cloud project, or set up a Supabase custom domain.
• You added your app's address to Google, and the error didn't go away.

Google sign-in through Supabase goes: your app → Google → Supabase callback → your app.

When your app starts sign-in, Supabase sends the user to Google with two values: the Client ID stored in Supabase, and a redirect_uri, which is Supabase's own callback. Google's docs say the redirect_uri “must exactly match one of the authorized redirect URIs for the OAuth 2.0 client”, and that “the http or https scheme, case, and trailing slash ('/') must all match”. If it doesn't match, Google stops with redirect_uri_mismatch.

The usual causes:

1. Your app's address is in Google's redirect URIs instead of the Supabase callback. For example https://myapp.com/auth/callback is listed, but Supabase sends https://abcd1234.supabase.co/auth/v1/callback.
2. A small difference: a trailing slash, http instead of https, a typo in the project ref, or a stray space.
3. The wrong OAuth client. You edited client A in Google Cloud, but Supabase has the Client ID of client B (or of a client in another Google Cloud project).
4. A Supabase custom domain was turned on. Supabase's docs say that once a custom domain is active, “OAuth flows will advertise the custom domain as a callback URL”. Google now receives https://auth.yourapp.com/auth/v1/callback, which isn't on the list.
5. Lovable with your own Google credentials, and a new custom domain. Lovable's docs say that when you connect a custom domain later, Lovable adds a redirect URL for it but doesn't select it, and “until you do, Google sign-in fails on the new domain with a redirect URI mismatch error”.
6. You just fixed it, but Google hasn't applied it yet. Google says changes to these settings can take 5 minutes to a few hours.

1. Read the redirect_uri Google received

On the Google error page, open error details (or “Request details”). It shows a line like:

redirect_uri=https://abcd1234.supabase.co/auth/v1/callback

That is the exact value Google needs on its list. You can also read it from the address bar of the Google page: it contains client_id=... and redirect_uri=... (URL-encoded, so : shows as %3A and / as %2F).

2. Check you're editing the right Google OAuth client

In Supabase, open Authentication → Providers → Google and copy the Client ID. In Google Cloud Console, open Google Auth Platform → Clients and open the client whose ID matches exactly. Check the project picker at the top: it's easy to be in the wrong Google Cloud project. The client type must be Web application.

3. Add the Supabase callback as an Authorized redirect URI

On that client, under Authorized redirect URIs, add the callback URL shown on Supabase's Google provider page:

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

• No trailing slash, https, exact project ref.
• If you use a Supabase custom domain (for example auth.yourapp.com), add both, as Supabase's docs recommend: https://<project-ref>.supabase.co/auth/v1/callback and https://auth.yourapp.com/auth/v1/callback.
• For local development with the Supabase CLI, Supabase's docs use http://127.0.0.1:54321/auth/v1/callback. Google allows plain http only for localhost addresses.

Click Save.

4. Put your app's address in the right places

Your app's address does not go in Google's redirect URIs. It goes in:

• Google → Authorized JavaScript origins: https://yourapp.com (and https://www.yourapp.com if you use it). No path, no trailing slash. A wrong origin gives a different error, origin_mismatch.
• Supabase → Authentication → URL Configuration: Site URL https://yourapp.com, and your callback route in Redirect URLs (for example https://yourapp.com/**). If this part is wrong, Google sign-in succeeds but users land on localhost or the home page. That's a different problem, covered in Google log-in sends people to localhost after I publish.

5. Lovable apps

• Managed by Lovable Google sign-in: Lovable handles the Google side, and its docs say it needs no change when you connect a domain. If you see this error with managed sign-in, check that your code doesn't call Google with its own client ID.
• Your own credentials: open More → Users → Settings → Google. Lovable lists every redirect URI it may use (your lovable.app address and each custom domain). Add every one of them to Authorized redirect URIs in Google Cloud, come back, select each one in Lovable, and click Save. Lovable's docs: “Redirect URIs must match exactly. Scheme, domain, path, and trailing slashes all matter.”

6. Wait, then test in a private window

Give Google at least 5 minutes (it can take a few hours). Then open your live site in a private window, click “Sign in with Google”, and check you come back signed in. Test both yourapp.com and www.yourapp.com if both are live.

Paste this into Lovable, Bolt, Cursor, Replit, v0 or whichever tool you build with. Replace the parts in brackets first. Most of the fix is in the Google and Supabase dashboards, so the prompt asks the AI to check the code and give you an exact checklist.

Google sign-in on [https://yourapp.com] fails with "Error 400: redirect_uri_mismatch".
Google's error details show: redirect_uri=[paste the value from the Google error page].
We use Supabase Auth with Google ([Lovable managed / our own Google OAuth client]).

Do only this:
1. Find every place in the code that starts Google sign-in. Confirm it uses supabase.auth.signInWithOAuth({ provider: 'google' }) and does not call accounts.google.com directly or set its own Google client_id or redirect_uri.
2. Confirm any redirectTo is built from window.location.origin (no hardcoded localhost or preview URLs).
3. Give me a checklist with the exact values for: Google "Authorized redirect URIs" (the Supabase callback, plus the custom-domain callback if we use one), Google "Authorized JavaScript origins", Supabase Site URL and Supabase Redirect URLs, for this domain.
Don't change the UI, other sign-in methods or the database.

This error comes back whenever something on the path changes: a new custom domain, a new Supabase custom domain, a new Google OAuth client, or a move to another Google Cloud project. After any of those, do one Google sign-in on the live site in a private window. Keep a note of the four values (Google redirect URIs, Google JavaScript origins, Supabase Site URL, Supabase Redirect URLs) with your publishing notes.

Heedza's log-in check opens your live log-in page on a schedule and sends you a screenshot and a fix prompt if the page stops opening or its form disappears. It never signs in, so it can't click through to Google and won't see this error. Do the private-window test yourself after domain changes.