Error 400: redirect_uri_mismatch, what it means and how to fix it

Why it happens

Google's OAuth documentation defines the error as: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID." The value "must exactly match one of the authorized redirect URIs for the OAuth 2.0 client", and "the http or https scheme, case, and trailing slash ('/') must all match."

So the user's Google account is not the problem. The check is between two strings: the redirect_uri your app put in the request, and the list saved on one specific OAuth client. The usual reasons they differ:

• The URI was never added (new domain, new callback route, new environment).
• It was added to a different OAuth client than the one whose client_id the app sends.
• It was added with a small difference: http vs https, www vs no www, a trailing slash, a different port or path, or different letter case.
• The change was saved minutes ago. Google says "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Step 1: Find the exact redirect_uri and client_id your app sent

Don't guess the value. A redirect-based Google authorization request carries redirect_uri and client_id as query parameters on Google's authorization endpoint, https://accounts.google.com/o/oauth2/v2/auth.

The most reliable place to read it is the request itself:

1. Open your browser's developer tools on the page that starts sign-in, go to the Network panel and tick Preserve log so requests survive the page change. If sign-in opens a popup, the request happens in the popup window, so inspect that window or copy the URL from its address bar.
2. Type accounts.google.com in the filter box and start sign-in.
3. Select the first request to accounts.google.com/o/oauth2/... and open the Payload tab. Chrome shows the query string parameters decoded by default. Copy redirect_uri and client_id.

If you can copy the full sign-in URL from the address bar instead, this prints the two values decoded:

// Paste the full https://accounts.google.com/o/oauth2/... URL between the quotes
const url = new URL("PASTE_THE_FULL_URL_HERE");
console.log("redirect_uri:", url.searchParams.get("redirect_uri"));
console.log("client_id:", url.searchParams.get("client_id"));

Google's error page may also offer developers a link to more details about the request; if you see one, the values there should match what you read above.

Where the value usually comes from:

Step 2: Compare it with Google's exact-match rules

Any one of these differences is enough to trigger the error:

Google also rejects some redirect URIs outright when you try to register them, so a URI you can't save is a sign the app should send something else:

• It must use https://. "Localhost URIs (including localhost IP address URIs) are exempt from this rule."
• "Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule."
• No wildcard characters (*), no fragment (#...), no userinfo (user:pass@), no path traversal (/..).
• "Host TLDs (Top Level Domains) must belong to the public suffix list."

A hidden cause of the scheme row: if your app runs behind a proxy or load balancer that ends HTTPS, server code that builds the callback from the incoming request can produce an http:// URI. In Express, the trust proxy setting makes req.protocol reflect the X-Forwarded-Proto header your proxy sets:

// Express: trust the one proxy in front of the app (load balancer / platform router)
app.set("trust proxy", 1);

Express warns that the trusted proxy must overwrite X-Forwarded-* headers, so set this to match your actual proxy setup.

Step 3: Add the redirect URI in Google Cloud console

Console labels as of Oct 2026:

1. Open Google Cloud console and select the project that owns the OAuth client.
2. Go to Google Auth Platform > Clients. Older guides and menus call this APIs & Services > Credentials.
3. Open the OAuth 2.0 client whose Client ID equals the client_id from Step 1.
4. Under Authorized redirect URIs, add the exact redirect_uri from Step 1, character for character.
5. Save.
6. Wait before retesting. Google says changes can take 5 minutes to a few hours.

If the value your app sent is the wrong one (an http:// URI in production, a stray trailing slash, a preview hostname), fix the app instead, so it sends the URI you meant to register.

Authorized JavaScript origins are a different list. An origin "includes the scheme and fully qualified hostname only"; a redirect URI includes "the scheme, fully qualified hostname, and path". Adding an origin does not fix redirect_uri_mismatch.

Using Firebase Authentication?

With Firebase's popup and redirect sign-in, Google sends the user back to https://<your authDomain>/__/auth/handler, and Firebase's troubleshooting FAQ lists https://PROJECT_ID.firebaseapp.com/__/auth/handler as the redirect URI for a project's web client. The error typically appears after authDomain is changed to your own domain without adding the new handler URI. The full steps for that case are in redirect_uri_mismatch after changing authDomain, and what the handler path does is explained in the Firebase auth handler.

How to confirm it worked

1. After the wait in Step 3, start sign-in again from your app.
2. You should get Google's account chooser or consent screen instead of the Error 400 page.
3. If the error is still there, repeat Step 1 and compare the new redirect_uri and client_id with the client's list character by character, using the table in Step 2.
4. If Google now passes but your app shows a different error, look it up in Firebase Auth errors.

Related problems

• Only failing on your dev machine: redirect_uri_mismatch on localhost.
• Started after moving Firebase's authDomain: redirect_uri_mismatch after changing authDomain.