Sealed-bundle verifier
Verify a sealed bundle
A sealed .see bundle is tamper-evident and forgery-detectable: any later change to its manifest, artifacts or signatures breaks the checks below. This page computes verification server-side, in memory, and stores and logs nothing about your bundle.
Stage 01 · Bundle input
Drop a sealed bundle here
or choose a .see file — up to 32 MiB
The bundle is verified server-side: its bytes are checked in memory and are not stored, logged, or shared. Nothing about your bundle leaves this page's request.
Stage 02 · Integrity & signature
Container, canonicalisation, signatures, artifact hashes and log proofs appear here after a bundle is verified.
Stage 03 · Log liveness
Whether the bundle is still contained in the transparency log's current head is shown here after verification.
Stage 04 · Log timeline
The log's recent leaves and key history appear here after a bundle is verified.
Reading the result
- PASS — bundle intact
- Every check the verifier ran is listed with its own marker. A PASS means the container parses, the manifest is canonical, the platform signature (and any customer cosign) verifies, and every artifact hash matches the manifest byte for byte.
- Log liveness — the anti-rewrite check
- When a bundle claims a transparency-log anchor, the verifier proves with a consistency proof that the tree the bundle was committed to is still contained in the log's current signed head — so entries cannot be quietly rewritten or dropped after the fact.
- FAIL — a coded, specific failure
- Verification fails closed: the first hard failure stops the process and names itself, so a FAIL is never ambiguous. There is no partial pass.
The independent path
Verification here is computed server-side, by the same open verifier the platform runs. You do not have to take this server's word for it: the npm CLI verifies the identical bundle fully offline, with no network and no trust in this page. Treat this tool as the fast path and the CLI as the independent one — developer docs.