Google sign-in redirect_uri_mismatch after deploy

This one applies if your app talks to Google directly. In Google Cloud, open the Google Auth Platform, then Clients, and open your OAuth client. The Authorized redirect URIs list holds every address Google may send people back to.

Google's docs say the redirect URI your app sends must exactly match one of the authorized redirect URIs. The http or https scheme, the case and the trailing slash must all match. Outside localhost, redirect URIs must use https.

Copy the address your app uses on the live site and add it to the list exactly. Then save.

Test again after a short wait before you change anything else.

If your app signs in through Supabase Auth, Google sends people back to Supabase first, and Supabase then sends them to your app. So the Google OAuth client needs the Supabase callback URL.

In Supabase, open Authentication, then Sign In / Providers, then Google. Copy the callback URL shown there. It ends in /auth/v1/callback. In Google Cloud, paste it under Authorized redirect URIs on the OAuth client.

Supabase's Google guide also says to add your app's URL under Authorized JavaScript origins. If your app lives at https://example.com/app, add https://example.com. Remove any localhost origin before you go to production, as the guide says.

Supabase's docs say the Site URL is the default redirect when your code sets no redirectTo. They tell you to change it from http://localhost:3000 to your production URL. If it still says localhost, people land there after Google sign-in.

The same docs say the redirectTo in your code should match the Redirect URLs list. Open Authentication, then URL Configuration, and add your live address, for example https://yourapp.com/**. In the list, ** matches any sequence of characters. A single * stops at a dot or a slash.

Then check the redirectTo value in your sign-in code. If it is hardcoded to localhost, change it to your live address.

supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo: "https://yourapp.com/welcome" },
})

https://www.yourapp.com and https://yourapp.com are two addresses. Because Google wants an exact match, a client that lists one fails on the other. Supabase's Redirect URLs list works the same way, entry by entry.

Add both versions in Supabase under Redirect URLs, and both under Authorized JavaScript origins in Google. With plain Google OAuth, add the redirect URI for each version too.

Vercel's docs say that if a visitor uses a domain with or without www, Vercel will attempt to redirect automatically. They recommend one primary domain with a redirect from the other. Then check that the address in the browser is the one you registered.

Each Vercel preview deployment has its own address. For Supabase, the docs show a Vercel setup: set the Site URL to your official URL, and add https://*-<team-or-account-slug>.vercel.app/** to Redirect URLs for deployment previews. Replace the slug with yours.

Google is stricter. Its docs say redirect URIs cannot contain wildcard characters. With plain Google OAuth, each preview address needs its own entry, or you test sign-in on one fixed address.

With Supabase, Google only needs the Supabase callback from step 2. The preview wildcard belongs in the Supabase list.