MundoKit

WebAuthn passkey response decoder

Paste response JSON or select a base64url binary input format. Inspect decoded fields locally; decoding does not verify or authenticate the response.

Inspect pasted WebAuthn data locally after JavaScript loads. This is a decoder, not an authentication verifier.

How it works

Authenticator data begins with a 32-byte relying-party ID hash, one flags byte and a 4-byte unsigned big-endian counter. The UP, UV, BE, BS, AT and ED bits describe user presence, user verification, backup eligibility, backup state, attested credential data and extensions.

When AT is set, the decoder reads an AAGUID, credential ID length, credential ID and a COSE public-key map. When ED is set, it reads an extension map. Attestation objects expose fmt, authData and attStmt. COSE labels are annotated by key type; unknown fields remain visible.

Binary integers are read without rounding. CBOR integers beyond JavaScript’s safe range are displayed as typed decimal strings. Byte strings become length/hex objects; maps become entry lists to preserve key types. Floating-point map keys have explicit type labels, so integer 1 and float 1.0 remain distinct. Leading U+FEFF in CBOR text is preserved. Non-finite floats and negative zero receive explicit display forms.

Worked examples

User presence with counter 42

The built-in sample contains 37 bytes: a zero-filled 32-byte RP ID hash, flags 0x01 and counter bytes 00 00 00 2a. It decodes to UP=true and signCount=42. The synthetic hash does not identify a real relying party.

Presence, verification and backup flags

A 37-byte authenticator-data record with flags 0x1d (decimal 29) and counter bytes 00 00 01 00 has UP, UV, BE and BS set and a counter of 256. AT and ED are unset.

Scope and interpretation

This zero-dependency inspector implements a bounded definite-length CBOR subset. It supports integer, byte/text, array, map, simple and floating-point values. Tags are displayed without interpretation. Indefinite-length CBOR and complex map keys are explicitly rejected. It is not a general CBOR conformance validator or a maintained third-party CBOR library.

It does not verify signatures, challenges, origins, RP ID hashes, attestation trust chains, curve points or credential ownership. No WebAuthn ceremony is started. A zero counter is not proof of an error: authenticators without a signature counter leave it at zero.

Application limits: 256 KiB text or binary input, 10,000 lines, 64 nested levels and 10,000 CBOR items. Input JSON uses base64url strings for binary fields; native ArrayBuffers must first be serialized by your application. No input is uploaded or saved.

Frequently asked questions

Does decoding verify a passkey login?
No. It only interprets bytes. A relying party must perform the verification steps in WebAuthn, including signature, origin, challenge and RP ID checks.
What is the difference between UP and UV?
UP records user presence. UV records user verification. Decoded flags are untrusted until the signed response has been verified.
What do BE and BS mean?
BE means backup eligible; BS means currently backed up. BS set while BE is clear is an invalid combination, which this inspector reports.
Why are CBOR maps shown as entries?
CBOR permits integer and other non-string keys. Entry lists preserve key types, so the integer label 1 is not confused with the text key "1".
Does a counter of zero mean a cloned authenticator?
No. Some authenticators do not implement a signature counter. Counter comparisons need stored credential state and relying-party policy; this tool makes no clone determination.
Can I paste padded base64url?
Yes, if padding and unused pad bits are valid. Standard base64 + and / characters are rejected; use the URL-safe - and _ alphabet.

Sources

Last reviewed 2026-11-14; next review due by 2027-02-12. The method is written out above so you can check our math.