Guide

Google sign-in "redirect_uri_mismatch": how to fix it on Supabase, Lovable and Base44 apps

Updated 20 October 2026

A person taps Sign in with Google and lands on a Google error page with redirect_uri_mismatch instead of your app. It often appears right after you connect a custom domain. Google documents the error in its OAuth 2.0 errors list.

What the error means

Google says: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID." Google sends people back only to addresses listed on your OAuth client, and "the http or https scheme, case, and trailing slash ('/') must all match."

In an app on Supabase, the address Google returns to is not your app. It is your Supabase project's callback address, and Supabase then sends the person on to your app. In Lovable and Base44, it is the address their own documentation gives. So the fix is almost always on Google's side, in the client's list of Authorized redirect URIs.

The causes, and how to fix each one

If Google's error page shows the redirect_uri it received under the error details, copy that value first; it tells you what is missing.

1. The Supabase callback address is not on the Google client

Supabase says to add your project's callback URL, shown on the Google provider page of the dashboard, to the client's Authorized redirect URIs.

How to fix it

In the Supabase dashboard, open the Google provider page and copy the callback URL.
In Google Cloud, open Google Auth Platform, then Clients, and open your Web application client.
Under Authorized redirect URIs, add the callback URL exactly as copied, then save.
Wait and retry. Google says changes "may take 5 minutes to a few hours" to take effect.

Source: Supabase: Login with Google, Google Cloud Help: Manage OAuth clients

2. The address changed: a new custom domain

Connecting a custom domain can change the address the sign-in flow uses, and the old entry on the Google client no longer matches. A public example: after changing the Supabase custom domain, the fix was to take the link shown in the error details, reshape it into a plain redirect URI and add that to the Google client (WeWeb community thread). Lovable documents the same for its "Your own credentials" mode: until you add the new domain's redirect URI, "Google sign-in fails on the new domain with a redirect URI mismatch error."

How to fix it

Copy the redirect_uri shown in Google's error details.
Add it to the client's Authorized redirect URIs (as a plain address, without the extra parameters), keeping the old one if the old address is still in use.
On Lovable with your own credentials, also select the new redirect URI in More, then Users, then Settings, then Google, and click Save.

Source: Lovable: Google sign-in, Google: Using OAuth 2.0 for web server applications

3. The entry is almost right

A missing or extra trailing slash, http instead of https, or different letter case is enough. Google's rules also say redirect URIs must use https (localhost is the exception), cannot contain wildcards, and cannot contain a fragment.

How to fix it

Compare the entry with the redirect_uri in the error details character by character.
Use https for every address that is not localhost.
Replace any wildcard entry with the exact addresses.

Source: Google: Using OAuth 2.0 for web server applications, Google Cloud Help: Manage OAuth clients

4. Lovable with your own Google credentials: a selected URI is missing in Google

In Lovable's "Your own credentials" mode, every redirect URI you select in Lovable must also be on the Google client. In "Managed by Lovable" mode, Lovable handles the Google setup.

How to fix it

In Lovable, open More, then Users, then Settings, then Google and note every selected redirect URI.
Add each one to Authorized redirect URIs on your Google client, matching exactly.
Save in both places.

Source: Lovable: Google sign-in

5. The Google client is the wrong type

Lovable says to use a Web application client: "Mobile or desktop client types are not compatible with Lovable's redirect flow." Supabase's guide also creates a Web application client for web apps.

How to fix it

In Google Auth Platform, then Clients, check the client's type.
If it is not Web application, create a Web application client, add the redirect URIs, and enter its Client ID and secret in your app's settings.

Source: Lovable: Google sign-in, Supabase: Login with Google

6. Base44 with custom Google OAuth: the Base44 callback is missing

Base44's custom Google OAuth asks for one specific redirect URI. It also needs a Builder plan or higher, a payment method on the Google Cloud project and a custom domain connected to the app.

How to fix it

On your Google client, set Authorized redirect URIs to https://app.base44.com/api/apps/auth/callback, as Base44 documents.
Set Authorized JavaScript origins to your app domain.
In Base44, open Dashboard, then Settings, then Authentication, and check that the Client ID and Client Secret match that client, then click Update.

Source: Base44: Managing login and registration

Why you cannot see it yourself

You're signed in, your customers aren't. You may have signed in before the domain change, or you are still signed in, so you never pass through Google's check again. A new person on the new address meets it on their first tap.

Frequently asked questions

The address in Google looks identical, but I still get the error. What now?

It happens. Compare with the redirect_uri in Google's error details, not with what you think the app sends: check the trailing slash, http or https, and letter case. Then allow time: Google says changes may take 5 minutes to a few hours.

Do I put my app's address or the Supabase address in "Authorized redirect URIs"?

For Supabase sign-in, the Supabase callback URL from the Google provider page goes in Authorized redirect URIs. Your app's own address goes in Authorized JavaScript origins, and it also has to be on Supabase's Site URL or Redirect URLs list.

Sign-in works, but people land on localhost or the wrong page afterwards. Is that the same error?

No. That is Supabase's side: the address your app returns to must be on the Redirect URLs list, and when the app gives no address Supabase uses the Site URL. See Supabase redirect URL localhost.

Can VibeFix fix it for me?

Yes, if you ask. The free check confirms the problem first. Our AI agent can find the cause, fix it in your code and re-check your live app: $79 for one bug, paid up front. If we can't complete your re-check, you get your money back.

Related guides

Sources (official documentation)

Fixed it? Prove a real stranger gets in

After the fix, the proof is a person who has never signed in tapping Sign in with Google on your live address and landing inside your app. Your own account cannot show that, because it is not new. Your AI reads your code. VibeFix signs up like a stranger.

Free check. An AI agent signs up to your live app as a brand-new person, with a real inbox of its own, on a phone and on a computer. You get the problem count, what each problem is, and one screenshot. It never changes your app and never emails your users. Test my app, free

VibeFix is independent. Google, Supabase, Lovable and Base44 are trademarks of their owners.

Want it fixed?

Our AI agent finds the cause, fixes it in your code and re-checks your live app. $79 for one bug, paid up front. If we can't complete your re-check, you get your money back.

It starts with a free check that confirms the problem on your live app, no account needed.

Get it fixed — free check first

More guides