Instantly verify if your browser and device support Face ID, Touch ID, Windows Hello, and FIDO2 security keys.
The checker reads the current browser environment and pre-fills the fields below. You can also override the inputs to inspect a copied user agent string or simulate a different client profile without reloading the page.
navigator.userAgent. Pasting a different value changes browser-family heuristics immediately.
The output updates instantly as each input changes. Status messages stay deterministic for the same input combination and do not require a network request or page reload.
The checker is waiting for browser capability signals.
Conceptual calculation: The checker combines four browser-facing inputs with navigator-exposed capability probes. It checks whether PublicKeyCredential exists, whether the browser reports a user-verifying platform authenticator, whether user-agent client hints are available, whether the page is running in a secure context, and whether conditional mediation can be queried for passkey-style autofill experiences.
Key assumptions: The reported platform authenticator state reflects what the browser can access at the time of the check. A supported browser still requires OS-level enrollment, device policy allowance, and relying-party implementation. The readiness score is a weighted compatibility indicator, not a cryptographic assurance level.
Limitations and edge cases: Private browsing, enterprise policy, remote desktop sessions, virtual machines, disabled biometric enrollment, iframe restrictions, and browser privacy defenses can all suppress or distort the observable signals. Some browsers support security keys even when platform biometrics are not available. Client hints can be absent without affecting actual WebAuthn support.
Open the page in the browser you want to validate. The tool auto-populates the current user agent, then checks whether the WebAuthn interface and platform authenticator probe are available. If you are auditing another device, paste its user agent string and adjust the toggles to mirror that environment.
Use the refresh button after changing browsers, enabling biometrics at the OS level, or moving from HTTP to HTTPS so the detection reflects the new state immediately.
The score combines browser API availability, platform authenticator presence, secure-context status, user-agent hint richness, and conditional mediation support. WebAuthn availability carries the largest weight because it is the minimum requirement for passkey flows. Platform and conditional mediation signals refine the score from basic compatibility toward production readiness.
The calculation remains deterministic: identical inputs always produce the same output labels and the same readiness score.
A high readiness score means the browser exposes the signals typically required for passwordless authentication. A medium score often means the browser supports WebAuthn but lacks either a platform authenticator or conditional mediation. A low score usually means the environment is missing WebAuthn, secure context, or both.
The detailed status cards matter more than the single score when you are troubleshooting enrollment failures.
This checker is an environment-assessment aid. It does not create or validate a credential, and it does not test server-side origin binding, relying-party identifiers, attestation policy, or account recovery behavior. Use it to narrow down likely compatibility issues, then verify the full sign-in flow in the target application.
Operational decisions should not rely on this page alone when a production authentication rollout or security acceptance review is involved.
Biometric login on the web is not a single feature toggle. A successful WebAuthn or passkey experience depends on the browser exposing the relevant interfaces, the operating system allowing access to a credential provider, the device having a usable authenticator, and the application invoking the correct ceremony under a secure origin. When any layer is incomplete, a user can see confusing messages such as "biometrics unavailable" even though the device itself has fingerprint or face recognition.
The browser decides whether the page can call the Web Authentication API, whether the request is allowed in the current context, and whether convenience features such as conditional mediation are available. Browsers also mediate the dialog that lets users choose between a platform authenticator and a roaming security key.
The operating system provides the biometric enrollment, device unlock policy, and authenticator plumbing. A browser may fully support WebAuthn while still reporting no platform authenticator because the user has not enrolled a fingerprint, face profile, or device PIN. For enterprise fleets, policy controls can also disable these paths even when the hardware is present.
WebAuthn is the browser API and protocol surface. Passkeys are user-facing discoverable credentials that often use WebAuthn under the hood. Biometrics are one possible local verification method that protects access to the authenticator. This distinction matters because a browser can support passkeys through a security key or synced credential provider without using the device's biometric sensor at all.
Platform authenticators are bound to the current device. Typical examples include Windows Hello, Touch ID, Face ID, or Android device credentials. They are convenient and usually provide the smoothest passwordless flow because the user can complete the ceremony without picking up another device.
Cross-platform authenticators are separate from the current device, such as USB, NFC, or Bluetooth security keys. They are useful for administrators, shared workstation environments, and higher-assurance policies because they can be issued, rotated, or required independently of the laptop or phone.
Developers can use the checker early in triage to determine whether a failure is likely rooted in browser capability, secure-context mistakes, or missing local enrollment. System administrators can use it before a rollout to spot which managed browsers expose the required signals for passkey enrollment and which ones will likely need a fallback policy.
| Scenario | Expected checker pattern | Likely operational meaning |
|---|---|---|
| Modern browser on a laptop with fingerprint enrolled | WebAuthn supported, platform authenticator available, secure context true, score high | Suitable for passkey enrollment and local biometric sign-in if the site implements WebAuthn correctly |
| Modern browser on desktop with a USB security key but no biometrics | WebAuthn supported, platform authenticator unavailable, cross-platform support likely, score medium | Passwordless sign-in is still feasible with a roaming authenticator even without fingerprint or face recognition |
| Managed browser with restrictive policy | API or probe appears unavailable despite modern device hardware | Local capability may be suppressed by enterprise configuration, privacy mode, or browser policy |
| HTTP page outside localhost | Secure context false, score reduced even when WebAuthn exists | Production passkey flows will be blocked until the relying party runs under HTTPS |
| Mobile browser with passkey sync but limited hints | WebAuthn supported, client hints limited or unavailable, score medium to high | Credential flows may work correctly even though environment attribution remains incomplete |
A device can physically include a sensor while still reporting no user-verifying platform authenticator because the operating system has not been configured. Enrolling a fingerprint, face profile, or device PIN often changes the outcome more than changing browsers.
Conditional mediation is associated with passkey-style account suggestions and autofill-like experiences. Its absence does not always block WebAuthn itself, but it usually means the user experience will be more explicit and less streamlined during sign-in.
User-Agent Client Hints help identify the browser environment more precisely, but they are not a prerequisite for WebAuthn. A browser may intentionally reduce or omit hint data for privacy reasons while still supporting passkeys and security keys.
For developer debugging, prioritize the WebAuthn and secure-context statuses first. For rollout readiness, focus on whether users have at least one reliable authenticator path: platform biometrics for convenience or roaming security keys for fallback and stronger account recovery control. Treat the score as a summary, then read the status notes to understand the exact limiting factor.
Enable fingerprint, face recognition, or device PIN at the operating-system level first, then use a browser and website that support WebAuthn or passkeys under HTTPS.
Platform authenticators live on the current device, while cross-platform authenticators are separate devices such as USB, NFC, or Bluetooth security keys.
The browser may lack WebAuthn support, the device may not have a biometric profile enrolled, the page may not be in a secure context, or policy settings may be blocking the authenticator probe.
In most cases, yes. WebAuthn reduces phishing risk and password reuse because private keys stay on the authenticator instead of being shared with the server.
Yes, if the browser exposes the relevant JavaScript interfaces. The final result still depends on device enrollment, operating-system support, and browser behavior.
No. A passkey can also be protected by a device PIN or unlocked through an external authenticator, depending on the platform and security policy.
Yes. Both can restrict available APIs, suppress client hints, or change how authenticator probes behave.
Review discoverable credential health, synced passkey behavior, and likely account-recovery friction across devices.
Inspect registration and assertion request parameters when a relying party needs lower-level troubleshooting signals.
Check whether origin security settings such as HTTPS and policy headers are aligned with modern authentication requirements.
Validate whether a roaming authenticator can be detected and used consistently across desktop and mobile clients.
Generate TOTP codes for accounts that still rely on app-based multi-factor authentication instead of passkeys.
Identify legacy cryptographic digests when investigating authentication stores, migration plans, or password reset pipelines.