Frequently asked questions
Common debugging questions developers ask before reaching for the Passkeys Debugger.
How do I debug a WebAuthn registration response?
Run a registration ceremony in the debugger or paste an existing attestation response into the response inspector. The Passkeys Debugger decodes the CBOR-encoded attestationObject, extracts authData (rpIdHash, flags, signCount, attestedCredentialData), decodes the credentialPublicKey from its COSE_Key encoding, and pulls the AAGUID — then shows the requested vs. returned user verification, attachment and transports so you can see where the authenticator diverged from your server options.
Try registration in the debugger →How do I test generateRegistrationOptions end-to-end?
The debugger accepts the same inputs @simplewebauthn/server's generateRegistrationOptions takes — rpName, rpID, userName, userID, userDisplayName, challenge, timeout, attestationType, excludeCredentials, authenticatorSelection (residentKey, userVerification, authenticatorAttachment), extensions, and supportedAlgorithmIDs — then runs a real registration in your browser. You see the full PublicKeyCredentialCreationOptions object passed to navigator.credentials.create() and the full parsed response, so you can validate every flag end-to-end without writing a server.
Configure options →Can I paste a passkey authentication response and parse it?
Yes. Use the response inspector to paste an authentication assertion (clientDataJSON, authenticatorData, signature, userHandle). The debugger decodes the authData flag byte (UP, UV, BE, BS, plus AT and ED), the RP ID hash, the signature counter, and any authenticator extension outputs (the CBOR map at the end of authData) — client extension results from getClientExtensionResults() are surfaced separately. The clientDataJSON challenge is decoded so you can confirm it matches the one you sent.
Open the debugger →How do I reproduce a Chrome passkey failure (NotAllowedError)?
Pick the registration or login flow, set the exact options your production server sends, and run it in the affected browser. Common Chrome failure modes: residentKey: "required" with a security key that doesn't support resident credentials, and userVerification: "required" on an authenticator without UV capability. With attestation: "direct", Chrome shows a user-consent prompt for cross-platform security keys (denial fails the call), while platform authenticators return a privacy-preserving none-equivalent attestation by design — including iCloud Keychain, which intentionally emits an all-zero AAGUID. The parsed response shows which options were honored.
How-to: test a platform authenticator →How do I test Bluetooth or hybrid transport on Android?
Open the debugger on the device under test (or use a Remote Test link to drive a phone from your laptop). The valid AuthenticatorTransport values are usb, nfc, ble, smart-card, hybrid, and internal. In practice, cross-device QR-code passkey flows use hybrid (formerly known as caBLE) — pure ble is rarely advertised by today's consumer authenticators. The parsed response shows the transports the authenticator actually returned, so you can confirm whether hybrid or another transport was used end-to-end.
How-to: test a security key →What does an AAGUID identify?
The AAGUID is a 128-bit identifier in the attestedCredentialData of authData that names the authenticator make and model — e.g. Google Password Manager, 1Password, YubiKey 5 NFC. Consumer iCloud Keychain intentionally emits an all-zero AAGUID for privacy, so it cannot be identified by AAGUID alone (only the MDM-managed variant emits a non-zero value). The debugger extracts the AAGUID on every registration and resolves it to a human name and icon using the community AAGUID map. Click any AAGUID to copy it.
See top authenticators →