Skip to content

Firebase Auth errorFirebase: “auth/account-exists-with-different-credential”

A user taps Sign in with Facebook, GitHub or another provider, and Firebase returns auth/account-exists-with-different-credential. With the default setting of one account per email address, that email already belongs to a user who signed in another way. Firebase won’t merge the two on its own, because that would let one provider take over another provider’s account.

Short answer

Keep the credential from the error, ask the user to sign in with the method they used before, then call linkWithCredential to add the new provider to that account. After that, both sign-in methods open the same user.

Why Firebase refuses the second provider, and the fix

  1. 01

    One account per email, two providers

    “To complete the sign in to the intended provider, the user has to sign first to the existing provider (Facebook) and then link to the former AuthCredential (Google ID token).” Firebase, Authenticate using Google with JavaScript (Handling account-exists-with-different-credential Errors)

    The email already belongs to a user who signed in with another provider. Save the pending credential from the error, sign the user in with their existing method, then link.

    try {
      await signInWithPopup(auth, new GithubAuthProvider());
    } catch (e) {
      if (e.code === 'auth/account-exists-with-different-credential') {
        const pending = GithubAuthProvider.credentialFromError(e);
        // e.customData.email holds the email; show a button first, popups need a user click
        const { user } = await signInWithPopup(auth, new GoogleAuthProvider());
        await linkWithCredential(user, pending);
      }
    }
  2. 02

    You can’t look up which provider the user had

    “A list of sign-in methods for a specified email address is no longer returned when calling the createAuthUri REST API or the fetchSignInMethodsForEmail client SDK method on all platforms.” Google Cloud, Email enumeration protection

    Older examples call fetchSignInMethodsForEmail to tell the user which provider to use. With email enumeration protection on, the default for new projects, it returns nothing. Ask the user how they signed up, or show the providers you support.

  3. 03

    The existing account uses a password

    If the earlier sign-up was email and password, sign the user in with it (or send a password reset), then link the pending social credential the same way.

  4. 04

    Google sign-in rarely hits this

    “A user logging in with Google will never cause this error when their account is hosted at Google” Firebase, Authenticate using Google with JavaScript

    Firebase treats Google as authoritative for accounts hosted at Google, including Gmail and Google Workspace, so a user signing in with Google is not blocked by an existing account on that email. The error mostly comes from Facebook, GitHub, Twitter and other providers.

Checked against the vendor’s docs on : Firebase docs: Authenticate using Google with JavaScript; Firebase docs: Link multiple auth providers to an account; Google Cloud docs: Email enumeration protection.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Firebase auth/email-already-in-use · Firebase Google sign-in popup blocked · Firebase auth/operation-not-allowed · Firebase phone auth invalid-app-credential

Questions

More on this error

Can I just allow multiple accounts per email?

Yes, in the Authentication settings, but each provider then creates a separate user with its own data. Most apps are better off with one account per email and linking.

Does this happen on Android and iOS too?

Yes. The native SDKs report the same condition, and the fix is the same: sign in with the existing provider, then link the new credential. In Flutter the code is account-exists-with-different-credential, without the auth/ prefix, and the pending credential is on the exception.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.