"Sign in with Google" fails for new people on my live app

It works for you. But a new person taps Sign in with Google on your live site and gets a Google error page, or lands back on your login page. Google's own error page tells them "only the app developer can fix this issue", so they leave.

The cause is almost always a setting, not code. Here's how to find which one.

Read the error Google shows

Open your live site in a private window, signed out of Google, and tap Sign in with Google. Google's error page names the problem:

• 400 redirect_uri_mismatch: the return address isn't on your Google client's list (fix 1).
• 400 origin_mismatch: your live site's address isn't on the list of allowed origins (fix 2).
• 403 access_denied: Google says this can mean "the app is in test mode and the developer hasn't added you as a test user" (fix 3).
• No Google error, but you land back on your login page: the sign-in service sent them to the wrong address afterwards (fix 4).

Fix 1: the return address Google allows

Google only returns people to addresses on your OAuth client's Authorized redirect URIs list, and Google's docs say the address must match exactly: "the http or https scheme, case, and trailing slash ('/') must all match".

• Supabase (including Bolt and most AI tools that use it): in Supabase, open Authentication → Providers → Google and copy the callback URL shown there. In Google Cloud, open your Web application client and paste it under Authorized redirect URIs. Note that this is Supabase's address, not your app's. If your Supabase project uses a custom domain, add that domain's callback too, "in addition to the Supabase project URL".
• Lovable, Managed by Lovable: nothing to set. Lovable's docs say managed mode "needs no change when you connect a domain".
• Lovable, your own Google credentials: when you connect a custom domain, Lovable adds its redirect URL to the list "but does not select it", and "until you do, Google sign-in fails on the new domain with a redirect URI mismatch error". Add that URL in Google Cloud, then select it in More → Cloud → Users → Auth settings → Google and save.
• Firebase with a custom domain: add https://<your-domain>/__/auth/handler to the redirect URIs. Firebase's docs say "the trailing /__/auth/handler is important".

Google notes that changes "may take 5 minutes to a few hours" to take effect, so wait before testing again.

Fix 2: your live site as an allowed origin

On the same Google client, add your live address under Authorized JavaScript origins, just the address with no path (for example https://myapp.com, not https://myapp.com/login). Add both www and non-www if people use both.

Fix 3: the app is still in "Testing"

In Google Cloud's sign-in settings, the app's publishing status can be Testing or In production. In Testing, Google limits access to listed test users, with one exception from Google's docs: if the app asks only for name, email and profile, which is plain Sign in with Google, people "do not need to be in the trusted user list".

So if new people get 403 access_denied, check two things: which permissions your app asks Google for (anything beyond name, email and profile removes the exception), and the publishing status. Moving to In production with Publish app opens it to everyone. Google says apps using only the basic permissions don't need its verification review.

Fix 4: where people land after Google

After Google, your sign-in service sends people back to your app, but only to addresses on its allowed list. In Supabase, open Authentication → URL Configuration, set Site URL to your live address and add every live address under Redirect URLs. On Lovable, use Auth settings → Advanced → Redirect URLs or ask Lovable in the chat. On Firebase, add your live domain under Authentication → Settings → Authorized Domains.

Some Google Workspace accounts fail

If only some people fail, and the error mentions "Error getting user email from external provider", Supabase's docs say some Google Workspace setups need the email permission requested explicitly. Ask your builder to request openid, email and profile when starting Google sign-in.

Check that new people can really sign up

For Google sign-in itself, the 2-minute test at the top of this page is the quickest check: a private window, signed out of Google, on your live site.

If your app also lets people sign up with an email address, paste its link at vibe-fixer.com for a free sign-up check. An AI agent signs up to your live app as a brand-new person, with a real inbox, on a phone and a computer, and tells you whether a new person can finish the email sign-up. It doesn't sign in with Google for you. No account needed.

Related: New users land back on the login page · Confirmation link opens localhost · Sign-up email not arriving