Free tool

Verify a receipt. Here, offline, without us.

The verifier that ships in the browser is the same one the issuer tests against. Paste a receipt, choose where the keys come from, and read the verdict. Nothing you paste leaves this tab.

Last updated 24 September 2026

Receipt JSON Statement JSON (optional — checks the render matches what was signed)

Trust material

Fetch the issuer's published keys and revocation lists once (/v2/jwks, /v2/revocations) I will paste them — verify with zero network calls Use the conformance-vector keys (for the samples below)

Try a sample

Samples come from tests/vectors/receipts/; each one is named for what it should be rejected for, so you can see every reason the verifier can return.

What is checked, in order

The receipt is an object with a signature, and its kid is in the JWKS.
A revocation list is present and verifies against the JWKS. If none does, the verifier fails closed — an unverifiable revocation list is treated as a reject, not a pass.
Neither the issuer key nor this receipt's nonce is on the revocation list.
For a v2 receipt, both halves of the hybrid signature verify: Ed25519 and ML-DSA-87 (FIPS 204). A receipt with one half stripped is rejected.
If you supplied the statement, the human-readable render in the receipt matches the statement that was signed, field for field.

The reject codes you can see here are the same ones the conformance suite asserts on, which is why the samples are named after them.

Ship this check in your own stack

The verifier is one file. The wire format and reject codes are specified.

Read the docs → Protocol spec