# redirect_uri_mismatch Google OAuth consent screen: how to fix

## TL;DR

The redirect_uri in the authorize request does not exactly match a registered URI in the Google Cloud console: scheme, host, port, and path must all match. Copy the URI from the error page into the console's authorized list. Google compares exact strings, not intentions.

```text
Error 400: redirect_uri_mismatch
```

## Steps

1. Copy the exact redirect_uri from the error page details.
   Expected: You have the real value.

2. Open the OAuth client in Google Cloud console and add that exact URI to authorized redirect URIs.
   Expected: The list contains it verbatim.

3. Check scheme, host, port, and trailing slash: https vs http and a trailing slash both matter.
   Expected: Every character matches.

4. Wait a few minutes for the change to propagate, then retry.
   Expected: The consent screen proceeds.

5. Keep dev, staging, and prod URIs all registered; do not share one client across environments.
   Expected: Each environment works.

## When to use

- Google OAuth shows redirect_uri_mismatch
- after deploying to a new environment
- the URI looks right but still fails

## When not to use

- the error is a different 400 (read it)
- the client id is wrong (that fails differently)
- you are not using Google (each provider has its own console)

## Tool compatibility

- Google OAuth2
- Google Cloud console

## Variant phrasings

- "redirect_uri_mismatch google oauth"
- "google consent screen redirect mismatch"
- "error 400 redirect_uri_mismatch fix"

## Why it happens

Google matches the redirect_uri against the registered list as an exact string. Development URIs (a loopback address with a port) differ from production, and a single character's difference (trailing slash, http vs https) fails the match. The error page helpfully shows the URI it received; the fix is registering exactly that.

## Edge cases

- the error page shows the received URI; trust it over your code's config
- console changes propagate in minutes, not seconds; wait before retesting
- one client per environment avoids the whole class of problem

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8nfA4Nu6hfMKHG9Q-pLNRw