Passkey Login — Free HTML CSS JS WebAuthn UI Snippet

Passwords are being replaced. Apple, Google, and Microsoft now ship passkeys — cryptographic credentials backed by Face ID, Touch ID, or Windows Hello — and modern login screens lead with a "Sign in with a passkey" button, keeping email as a fallback. This component is the front-end of that flow: a clean sign-in card with a primary passkey button that shows an authenticator-prompt loading state, a divider, an email field wired for passkey autofill, a fallback button, and a success toast. It is built in plain HTML, CSS, and vanilla JavaScript, and it feature-detects the real WebAuthn API so the demo behaves the way a production screen would.

The passkey-first layout

The card puts the passwordless path first: a fingerprint-style passkey button as the prominent dark primary action, an "or" divider, then the traditional email path below it as the secondary option. This ordering reflects the current best practice from the FIDO Alliance and the big platform vendors — surface the faster, phishing-resistant method, but never strand users who have not set up a passkey yet. The card has a gradient lock logo, a title, a subtitle that sets expectations ("no password to remember"), and a footer link to account creation.

Feature-detecting WebAuthn

When the passkey button is clicked, the script checks typeof window.PublicKeyCredential !== 'undefined' — the canonical way to detect whether the browser supports the Web Authentication API. In a real implementation this is the gate before calling navigator.credentials.get() with a server-issued challenge. Here it drives the demo's two outcomes: a "verified" toast when passkeys are supported, and a "not supported here" toast when they are not, so you can see both branches. This mirrors how you would progressively enhance a real login: show the passkey button only when the API exists, and fall back to email-and-password otherwise.

The authenticator-prompt loading state

Clicking the passkey button adds a .loading class to the card. Pure CSS then hides the button's icon and label and reveals a spinning SVG, communicating that the browser is waiting on the platform authenticator (the Face ID / Touch ID / Windows Hello system dialog). The button's pointer-events are disabled during this state so it cannot be double-triggered. A setTimeout simulates the 1.5-second authenticator round-trip; in production this period is exactly when navigator.credentials.get() is awaiting the user's biometric confirmation.

Passkey autofill on the email field

The email input carries autocomplete="username webauthn". That webauthn token is what enables "conditional UI" — browsers that support it will surface available passkeys directly in the email field's autofill dropdown, so a returning user can pick their passkey without even pressing the button. Including the token costs nothing on browsers that ignore it and unlocks the smoothest passkey experience on those that support it.

The success toast

Feedback is delivered through a pill toast pinned to the bottom of the card. It starts translated 80px down and transparent; adding a .show class slides it up and fades it in with a cubic-bezier spring, and a setTimeout hides it after 2.6 seconds. The toast has role="status" and aria-live="polite" so screen readers announce the result without stealing focus. The timer is cleared on each trigger so rapid clicks never leave it stuck.

Wiring to a real backend

To make this functional, replace the setTimeout with the real ceremony: fetch a challenge from your server, call navigator.credentials.get({ publicKey: { challenge, ... } }), and POST the resulting assertion back for verification. Keep the same UI states — add .loading before the call, remove it after, and show a success or error toast based on the response. Swap the #6366f1 / #0f172a palette and the logo for your brand, and edit the title and subtitle to match your product.