Skip to content
Get a quote

Google sign-inGoogle sign-in: Error 400: redirect_uri_mismatch

Users click Sign in with Google and get Google’s error page instead: redirect_uri_mismatch. It often appears after a move to a new domain, or the first time the app runs outside localhost. Here’s what Google checks, and where the right address comes from in Supabase and Firebase apps, or hand it over at a fixed price.

Short answer

Google only sends users back to addresses listed under Authorized redirect URIs on your OAuth client in the Google Cloud console, and the match must be exact: http or https, upper and lower case, and the trailing slash. Copy the exact callback address your auth provider uses, add it to the OAuth client the app actually uses, and try again.

Why the address doesn’t match, and the fix

  1. 01

    The address is close but not exact

    “Note that the http or https scheme, case, and trailing slash ('/') must all match.” Google, OAuth 2.0 for web server apps

    http instead of https, www versus no www, a different port or a missing trailing slash all count as a different address. Copy the redirect address from the error details or your auth provider and paste it into the OAuth client as it is.

  2. 02

    Supabase or Firebase uses its own callback address

    “This will also be used as the redirect mechanism for OAuth sign in.” Firebase, Authenticate with Google (web)

    With Supabase Auth, Google sends users back to your Supabase project’s callback URL, shown on the Google provider page in the Supabase dashboard (it ends in /auth/v1/callback), not to your app. With Firebase Auth, the default is your project’s firebaseapp.com domain, or your custom domain if you set one up, and the address ends in /__/auth/handler. Add that address, not your app’s page.

  3. 03

    The address is on a different OAuth client

    “The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID.” Google, OAuth 2.0 for web server apps

    Projects often have several OAuth clients, for example one for development and one for production. Check that the client ID your app or auth provider uses is the one you edited.

Checked against the vendor’s docs on : Google Identity: OAuth 2.0 for web server applications; Supabase docs: Login with Google; Firebase docs: Authenticate with Google (web).

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Supabase auth email links go to localhost · Firebase auth/unauthorized-domain · App Store Guideline 4.8 (login services)

Questions

More on this error

It works on localhost but not on my live domain. Why?

Each address needs its own entry. Add the live domain’s exact callback address to the OAuth client the live app uses, not only the localhost one.

Should I add localhost to production?

Keep development addresses on a separate development OAuth client where you can. Supabase’s guide says to remove localhost from the authorized origins when the app goes to production.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.

Describe your problem All fixes