Google sign-in fails with redirect_uri_mismatch on Supabase? Here's the fix

You add "Sign in with Google" to your app, click the button, and Google shows one of these instead of the account picker:

Error 400: redirect_uri_mismatch
Access blocked: This app's request is invalid
Unable to exchange external code

Google only sends users back to addresses listed in your OAuth client. With Supabase, that address is your project's auth callback, not your app. So the fix is: add the callback URL shown on the Supabase Google provider page to Authorized redirect URIs, add your site to Authorized JavaScript origins, and allow your app's return page in Supabase.

I see this one often in apps built with Lovable and Bolt on Supabase, usually the first time someone sets up Google sign-in for the live domain.

Why it happens

1. The Supabase callback is missing in Google Cloud. Authorized redirect URIs lists your app's address instead of the Supabase callback (https://<project-ref>.supabase.co/auth/v1/callback, or your custom auth domain).
2. You edited the wrong OAuth client. The client ID and secret in Supabase belong to a different Google Cloud client than the one you changed, or the client type isn't Web application.
3. The return page isn't allowed in Supabase. After Google, Supabase sends the user to your redirectTo address. If that address isn't on the Redirect URLs list, users land on the Site URL instead.
4. The audience is limited. While the Google consent screen is set to testing or internal users, anyone outside the allowed list is blocked.

Find the cause

1. On Google's error page, click error details and copy the redirect_uri value it shows.
2. In Supabase, open Authentication > Providers > Google and copy the callback URL shown there.
3. In Google Cloud, open Google Auth Platform > Clients, open the client whose ID matches the one in Supabase, and compare the two.

Fix 1: correct the Google Cloud client

• Under Authorized redirect URIs, add the exact callback URL from the Supabase Google provider page.
• Under Authorized JavaScript origins, add your site's origin only, for example https://app.example.com, with no path.
• Save, and make sure this client's ID and secret are the ones in the Supabase Google provider.

Fix 2: allow the page users come back to

Add your return page (for example https://app.example.com/auth/callback) to Redirect URLs in Supabase, then pass it from the app:

await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: window.location.origin + '/auth/callback' },
});

Fix 3: open sign-in to everyone

In Google Auth Platform, set the audience to external and publish the app when you're ready for public users. Brand verification can take a few business days, so don't leave it to launch day.

Check the fix worked

• Sign in with a Google account that has never used the app. It should come back to your callback page, signed in.
• Sign out, then sign in again from a private window and from a phone.
• Remove any localhost origins from the production client.

Stop it coming back

• Use one Google client per environment (development and production), so a change for one can't break the live app.
• Before launch, set up a custom auth domain so the Google screen shows your domain instead of supabase.co.

Quick answers

Should the redirect URI be my app or Supabase? Supabase. Google sends the user to Supabase's callback, and Supabase then sends them on to your app's redirectTo address.

How long do Google changes take? Usually a few minutes. Test in a private window so an old session doesn't hide the result.

Sources: Supabase: Login with Google and Supabase: Redirect URLs.

I first published this fix on our site: Fix Google sign-in redirect_uri_mismatch with Supabase. To check your live app for exposed keys, missing security headers and broken basics in about a minute, run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.