b2KIT

WebAuthn / FIDO2 Debugger

Test WebAuthn registration and authentication flows. Inspect attestation objects, assertions, and credential details.

Tested tool guide Tested browser tools Checked August 16, 2026

What WebAuthn / FIDO2 Debugger does, with a checked example

WebAuthn registration and sign-in ceremonies hand back binary CBOR structures that browsers and relying-party servers exchange but rarely show you directly. This debugger runs navigator.credentials.create() and .get() against the page it's loaded on, or accepts a pasted base64url attestationObject or assertion response, and decodes it: CBOR fields, the authenticatorData flag byte, RP ID hash, sign counter, and the attested credential's COSE public key. The most common surprise: attestation format 'none' with an empty attestation statement is the normal, expected result for platform passkeys, not a sign the ceremony failed.

Worked example

A concrete input and expected output from the current implementation.

Input

authenticatorData flags byte: 0x5D

Expected output

UP=1, RFU1=0, UV=1, BE=1, BS=1, RFU2=0, AT=1, ED=0 -> User Present, User Verified, Backup Eligible, currently Backed Up, attested credential data included, no extension data

0x5D is binary 01011101; reading bit 0 as UP up through bit 7 as ED per the WebAuthn authenticatorData flag layout gives that exact set of true/false values.

How the result is produced

1

Attestation object decoding

A pasted or captured attestationObject is CBOR-decoded into fmt, attStmt and authData. authData is then split byte by byte into the 32-byte RP ID hash, the 1-byte flags field, the 4-byte signature counter, and, when the AT flag is set, the attested credential block (AAGUID, credential ID, COSE-encoded public key).

2

Live ceremony capture

Given a challenge you supply, the tool calls navigator.credentials.create() or .get() in the current page context and reads back the resulting PublicKeyCredential: clientDataJSON (origin, challenge, type), and either the attestation response on registration or authenticatorData plus signature and userHandle on authentication.

Good uses

  • diagnosing why a relying-party server rejects a registration, for example an RP ID hash that doesn't match the expected domain
  • checking whether a passkey provider returned attestation format 'none', 'packed', or 'android-safetynet' before writing server-side verification code
  • reading the UV/BE/BS flag bits to confirm a credential is a synced multi-device passkey rather than a hardware-bound security key

Limits and checks

  • An attestation object proves little about the authenticator's make or model when fmt is 'none', which is the default for most passkeys and leaves no attestation certificate to inspect.
  • signCount is commonly 0 and stays 0 across repeated sign-ins for synced passkeys; that is expected per spec, not evidence your server-side counter check is broken.
  • Ceremonies can only be captured for the origin the tool itself is served from, since WebAuthn is origin-bound, so you cannot use this page to trigger or inspect a ceremony happening on a different site.

Common questions

Can I decode an attestation object without doing a live registration?

Yes. Paste the base64url-encoded attestationObject, or the full response your server received, and the tool CBOR-decodes it directly. No navigator.credentials call is made in that mode, so it works for debugging logs after the fact.

Why does the signature counter stay at 0?

Most synced passkeys (iCloud Keychain, Google Password Manager) report signCount as 0 on every assertion because a per-device counter is meaningless once a credential is copied across devices. Treat a persistently 0 counter as normal unless you're specifically testing a hardware security key.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools