Passkey Login: Immediate Mode

After a sign-in-relevant user gesture, immediate mode asks the browser whether it can offer an immediately available credential for this site. If it can, the account chooser menu opens before the user types an identifier. Otherwise, the request rejects silently and the normal login flow continues. That silence is the point. Every other login surface has to guess whether a passkey attempt will succeed. Immediate mode lets the browser answer, at the cost of being unable to tell you why it said no. A sign-in-relevant user gesture is a deliberate click or tap that shows the user wants to authenticate (not page load and not an unrelated interaction). Chrome requires this gesture before the call, which prevents silent probing. Typical examples:

Clicking a Sign in button on the login page
Starting Checkout (or a similar action) where signing in is useful but optional for guests

Support (August 2026): Chrome only; feature-detect the immediateGet capability rather than relying on a version number. Chrome 148 release notes listed the capability and Chrome 149 announced the broad launch. The API is not yet part of the WebAuthn specification, so treat it as a progressive enhancement on top of a login flow that already works without it.

Flow	User action needed	When the UI appears	If no passkey is available	Support
Immediate mode	The sign-in-relevant gesture that triggers the call	Before any identifier is entered	Rejects silently; the normal login flow continues	Chrome only; feature-detect `immediateGet`
One-Tap	One tap on the passkey button	After your app decides a passkey is likely	The button is not rendered	Cross-platform
Conditional UI	Focus the identifier field	When the user taps the input	No suggestions appear	Supported browser, OS and provider combinations; feature-detect
Identifier-First	Enter an identifier	After the identifier is submitted	Falls back to password	Cross-platform
Cross-Device via QR	Scan a QR code with a phone	When the client presents a remote route	The route fails or the user chooses an alternative	Desktop; needs Bluetooth and internet

Immediate mode and Conditional UI are easy to confuse because both can present a passkey without the user typing a username. The difference is who initiates: Conditional UI waits for the user to focus the input, while immediate mode fires on your call and resolves or rejects at once.

See the flow

Platform screenshots for this page are in production. Until they land, these recordings show the two ways to trigger immediate mode:

Sign-in button
Contextual action

Recordings by Google, from Immediate UI mode for logins (Chrome for Developers, May 2026), used under CC BY 4.0.

Your app requests an immediate login

On a user gesture (for example a “Sign in” click), the app calls navigator.credentials.get() with uiMode: 'immediate'.
A readiness layer may choose where to expose this enhancement, but prior credential-likelihood prediction is optional and can create false negatives. The required gates are feature detection, a meaningful gesture and a complete fallback path.

Chrome checks for locally available credentials

Chrome looks only at credentials it can present without further user action: passkeys held by a passkey provider such as Google Password Manager, Windows Hello or iCloud Keychain, and, when you pass password: true, passwords saved in Google Password Manager.
Cross-device (QR) and security key options are not offered in this mode.

Credential found: the account chooser opens immediately

The user picks an account and verifies with their screen lock.
Your server receives a normal assertion and completes the login. Nothing about the flow after this point is specific to immediate mode.

No credential found: the request rejects silently

The promise rejects with NotAllowedError and no UI is ever shown.
Your app renders its standard login form. The user does not see an error, because from their point of view nothing happened.

Implementation

async function tryImmediateSignIn() {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  if (!capabilities.immediateGet) return showLoginForm();

  try {
    const credential = await navigator.credentials.get({
      password: true, // also offer passwords saved in Google Password Manager
      publicKey: {
        challenge: serverGeneratedChallenge,
        rpId: 'example.com',
        // allowCredentials must be omitted or empty
      },
      uiMode: 'immediate',
    });
    return completeSignIn(credential);
  } catch (error) {
    if (error.name === 'NotAllowedError') return showLoginForm();
    throw error;
  }
}

Feature-detect with PublicKeyCredential.getClientCapabilities() and check the immediateGet key. Set uiMode: "immediate" alongside publicKey; when uiMode is omitted, the request follows its normal mediation behavior.

NotAllowedError is deliberately ambiguous. Chrome returns the same error whether no credential exists, the user dismissed the chooser, the session is incognito, or you sent a non-empty allowCredentials. This prevents sites from probing which users hold credentials, and it means you cannot branch on the reason: always fall back to your normal login form. Branch on error.name only; the message string is not part of the contract.

Constraints to design around

The call must follow a user gesture

Chrome requires a user gesture such as a click to initiate the request, which prevents silent probing on page load. Plan the call for a “Sign in” interaction rather than on first paint.

Incognito and private sessions always reject

Requests in incognito always throw NotAllowedError, so your fallback path is the only path for those users.

Allowlists are not permitted

A non-empty allowCredentials list causes the request to throw. Immediate mode is inherently a discoverable-credential flow.

The dialog cannot be dismissed programmatically

The signal parameter cannot be used to cancel the immediate login dialog once it is shown, so do not build UI that assumes you can withdraw the prompt.

Migrating from the origin trial: during the Chrome 139–141 origin trial this feature was requested with mediation: 'immediate'. A specification change in November 2025 moved it to the uiMode field, and mediation: 'immediate' no longer activates it. Replace it with uiMode: 'immediate' in the same position. See the origin trial announcement for the original shape.

Acceptance criteria

Benchmark as	User reach
Enhancement	Mid

Immediate mode removes an identifier step for eligible returning users, but its limited client availability means it must remain a progressive enhancement.

ID	Level	Acceptance criterion	How to verify
W1.6-AC01	Core	Unsupported clients and capability-check failures continue through the existing login journey without a blocker.	Run the flow with `immediateGet` available, unavailable and rejected; confirm only the supported case enters immediate mode and every other case reaches the standard flow.
W1.6-AC02	Core	Every immediate-mode request starts after a user click.	Invoke the route with and without a preceding click; confirm only the clicked path can start immediate mode.
W1.6-AC03	Core	If an immediate-mode request returns `NotAllowedError`, do not show an error or block login. Continue with the normal login flow.	Test no local credential, chooser dismissal, private or incognito mode and a rejected request. Every case continues to the normal login flow without an error.
W1.6-AC04	Core	Immediate mode is not the only passkey route: after silent fallback, a user can deliberately start a standard ceremony that may offer cross-device authenticators or security keys where supported.	Use a client with no local credential but an available phone or security-key credential; confirm silent fallback followed by the standard route can complete.
W1.6-AC05	Core	Successful immediate authentication resumes the action that initiated sign-in.	Complete immediate authentication from an explicit sign-in control and a contextual action; confirm each returns to its intended continuation.
W1.6-AC06	Core	The immediate request does not surface cross-device QR or security-key options.	Test with no local credential while a phone and security key are available; confirm the request falls through silently without those options.
W1.6-AC07	Core	Every immediate-mode request uses the documented immediate request-option shape.	Inspect the request for `uiMode: "immediate"`, `publicKey`, a fresh challenge, the correct RP ID and an omitted or empty `allowCredentials`.
W1.6-AC08	Core	The relying-party flow does not depend on an abort signal to withdraw an immediate chooser.	Trigger an abort after chooser presentation and confirm the surrounding application state remains correct if the chooser stays visible.

References

Relevant criteria: W1.6-AC01–AC08: Chrome for Developers: Immediate UI mode for logins defines feature detection, request constraints, silent fallback, Sign-in and Checkout continuation, private-mode behavior and the exclusion of cross-device and security-key options.

Overview

Web

Native

Passkey Login: Immediate Mode

See the flow

Implementation

Constraints to design around

Acceptance criteria

References

​Immediate Mode Login

​How this differs from the other login flows

​See the flow

​Implementation

​Constraints to design around

​Acceptance criteria

​References

Immediate Mode Login

How this differs from the other login flows

See the flow

Implementation

Constraints to design around

Acceptance criteria

References