When setting up Google login or working with APIs, many developers hit the same wall: Error 400: redirect_uri_mismatch. It may appear technical, but the cause is often something minor. Let’s walk through what it means, why it shows up, and how to solve it without wasting hours.

What does redirect_uri_mismatch mean?

What does redirect_uri_mismatch mean?

Google OAuth 2.0 uses a “redirect URI” — a return path where Google sends the user back after login. If the redirect URI your app sends is not the same as the one you saved in the Google Cloud Console, Google refuses the request and throws a 400 Bad Request error.

The mismatch can appear in different cases:

  • Logging in with Google on a WordPress plugin.
  • Signing into a SaaS platform.
  • Running a web app locally on localhost.
  • Testing on staging servers with a slightly different domain.

So in simple words: your app says, “Send users back here”, but Google says, “Sorry, that address isn’t on the list.”

Why does it happen?

There isn’t only one reason. It can be caused by many little mistakes that break the OAuth flow.

  • Redirect URI not added in Google Cloud Console.
  • HTTP instead of HTTPS.
  • Typo in the domain, missing subdomain, or wrong port number.
  • Localhost testing vs live domain mismatch.
  • Forgetting to include a trailing slash / at the end.

Even one of these is enough to block the request. Google is strict about it because redirect URIs help prevent phishing and redirect attacks.

Steps to fix redirect_uri_mismatch

Here’s the fix. It doesn’t take long if you know where to look:

  1. Log in to Google Cloud Console.
  2. Go to APIs & Services → Credentials.
  3. Find your OAuth 2.0 Client ID and open it.
  4. In the section Authorised redirect URIs, add the exact callback URL.
  5. Examples:
    • https://example.com/auth/google/callback
    • http://localhost:3000/auth/callback
    • https://staging.example.net/oauth/return
  6. Save the changes and restart your app or reload your site.

Always check character by character. A small typo or wrong slash is enough to trigger the mismatch.

Localhost vs production

Testing on your computer is different from running the app live. Local testing might use:

  • http://localhost:8080/callback
  • http://127.0.0.1:5000/oauth2/return

But your live site uses:

  • https://myapp.com/oauth/callback

Both must be added in the Google Cloud Console. If you forget one, the error shows up when you switch between environments. Some teams also add a staging domain. This way, all setups — local, staging, and production — keep working without edits each time.

Tips to avoid future issues

Here are some habits that save time:

  • Copy the URI from your app log instead of typing it by hand.
  • Always use HTTPS on live domains.
  • Don’t forget slashes at the end.
  • Keep a simple text file where you list all redirect URIs for your project.
  • Update them whenever you change domain names or move servers.

These small steps stop the redirect_uri_mismatch from showing up again.

Other OAuth errors you may see

This isn’t the only error developers face when working with OAuth. Some others are:

  • invalid_client → Wrong client ID or secret.
  • access_denied → User refused to give permission.
  • invalid_request → Missing required parameters.
  • unauthorized_client → Client is not allowed for the request.

Each looks different, but all point to misconfigured OAuth credentials or missing settings in Google Cloud Console.

Final words

The error 400 redirect_uri_mismatch is one of the most common roadblocks in Google sign-in. It happens when the return URL doesn’t match the list in Google Cloud Console. The fix is straightforward: add the correct redirect URIs, check spelling, and keep both local and live domains registered.

Once you understand why it happens, you can fix it quickly and keep Google OAuth sign-in running smoothly.

If you’ve faced this error before or found a different solution, share your experience in the comments. It might help the next person struggling with the same issue.