> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corbado.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Passkey Login: Immediate Mode

> Immediate mode can show the passkey account chooser menu immediately after a sign-in-relevant user gesture and stays silent when no passkey is available.

## Immediate Mode Login

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

<Info>
  **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.
</Info>

### How this differs from the other login flows

| 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](/passkey-ui-flows/web/passkey-login/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](/passkey-ui-flows/web/passkey-login/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](/passkey-ui-flows/web/passkey-login/identifier-first)   | Enter an identifier                                 | After the identifier is submitted          | Falls back to password                             | Cross-platform                                                  |
| [Cross-Device via QR](/passkey-ui-flows/web/passkey-login/cross-device-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:

<Tabs>
  <Tab title="Sign-in button">
    <Frame caption="The user clicks Sign in and the account chooser opens immediately">
      <video autoPlay loop muted playsInline controls className="w-full">
        <source src="https://mintcdn.com/corbado-43/prH0Omp6pLxd9sXk/images/authentication-flow/web-app/video/immediate-mode-explicit-flow.mp4?fit=max&auto=format&n=prH0Omp6pLxd9sXk&q=85&s=450af0f7437128854dad438e0bcdd6ac" type="video/mp4" data-path="images/authentication-flow/web-app/video/immediate-mode-explicit-flow.mp4" />
      </video>
    </Frame>

    The user clicks a dedicated **Sign in** button and the account chooser opens straight away. When no credential is available nothing is shown, and your normal form stays exactly where it was.
  </Tab>

  <Tab title="Contextual action">
    <Frame caption="A returning customer signs in from Checkout without leaving the flow">
      <video autoPlay loop muted playsInline controls className="w-full">
        <source src="https://mintcdn.com/corbado-43/prH0Omp6pLxd9sXk/images/authentication-flow/web-app/video/immediate-mode-implicit-flow.mp4?fit=max&auto=format&n=prH0Omp6pLxd9sXk&q=85&s=c88c370bd49b0286bcb92391750e9497" type="video/mp4" data-path="images/authentication-flow/web-app/video/immediate-mode-implicit-flow.mp4" />
      </video>
    </Frame>

    The user selects an action for which authentication is useful but not mandatory. Chrome uses **Checkout** as an example. Returning customers can authenticate in the current flow, while guests continue without authentication.
  </Tab>
</Tabs>

Recordings by Google, from [Immediate UI mode for logins](https://developer.chrome.com/docs/identity/immediate-ui-mode) (Chrome for Developers, May 2026), used under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### Implementation

```js theme={null}
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.

<Warning>
  **`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.
</Warning>

### Constraints to design around

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="Incognito and private sessions always reject">
    Requests in incognito always throw `NotAllowedError`, so your fallback path is the only path for those users.
  </Accordion>

  <Accordion title="Allowlists are not permitted">
    A non-empty `allowCredentials` list causes the request to throw. Immediate mode is inherently a discoverable-credential flow.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

<Note>
  **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](https://developer.chrome.com/blog/webauthn-immediate-mediation-ot) for the original shape.
</Note>

## 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](https://developer.chrome.com/docs/identity/immediate-ui-mode) 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.