Zero data collected. No tracking, no logs of what you seal. Everything runs in your browser.
The published standard · verify without us

The standard, published and pinned.

It proves the data has not changed since the moment you sealed it. It does not prove the data was true or authentic.

A VerifyBundle record is meant to be checked without trusting us. Everything needed to do that is published here: the offline verifier, the specification, and the conformance vectors. Each is pinned by a SHA-256 so you can confirm the file you hold is the exact one published, before you trust it to verify anything.

The hash is the point. Download an artifact from here or from anywhere it is mirrored, check its SHA-256 against the trust root below, and the source no longer matters. Verification is in-browser math over the bundle bytes: Ed25519 (RFC 8032) and SHA-256 (FIPS 180-4) for v1 records, plus ML-DSA-65 (FIPS 204) for the v2 post-quantum hybrid.

The artifacts, and their trust roots

Three files. The SHA-256 beside each is its trust root: recompute it after downloading and confirm it matches. If it differs, do not trust the file.

ArtifactSHA-256 (trust root) · size
verifier.html
The offline verifier: one self-contained HTML file. Open it directly, with the network off, and verify any record. No server, no account, no company, no network.
a817f34aa2f91e577c3b7cbe478cd0ccaba66f3bc492ab3f442fca0b9a31bfee
60,025 bytes
VERIFYBUNDLE_SPEC.md
The normative specification: the bundle and seal format, the canonicalization, the Merkle and checkpoint construction, and the verification rules. Enough to re-implement the verifier from scratch.
7cf0ebdf1dda6b24561ff0746a9050a17d676473de830983fde63a845b45f12a
29,335 bytes
verifybundle-conformance-vectors.zip
The golden conformance vectors (v1 Ed25519, and the v2 hybrid ML-DSA-65 + Ed25519), pinning the expected bytes so an independent re-implementation can prove it agrees.
f67a79351f0397be9be9afed6e527524f8b29027e52f3e12f9aa0fc2dec89d64
15,142 bytes
Verify a record yourself

Trust nothing we serve. This is exactly what a stranger does.

  1. Download verifier.html from the table above.
  2. Compute its SHA-256 and confirm it equals the trust root a817f34a…. If it differs, do not trust it.
    sha256sum verifier.html on Linux, shasum -a 256 verifier.html on macOS, or certutil -hashfile verifier.html SHA256 on Windows.
  3. Open the file directly (double-click, so it loads over file://), with the network disconnected.
  4. Drop in a .vbundle (or paste its bundle.json). A valid record shows VERIFIED; a tampered one shows FAILED. No server, no account, and no company is involved.

The verifier carries a Content-Security-Policy of connect-src 'none', so the browser blocks any network call at runtime, not merely in the source. It is reproducible: building it from source yields this exact file, byte for byte.

Re-implement the verifier from scratch

You do not have to use our verifier at all. Follow the specification and check your implementation against the conformance vectors, which pin the expected bytes for both signature profiles.

These same artifacts are also published as an immutable, dated release, so verification survives even if this site does not. Wherever you obtain a copy, the trust root above is what you check it against. A new dated release is published whenever the verifier changes.

ML-DSA-65 · FIPS 204  ·  Ed25519 · RFC 8032  ·  SHA-256 · FIPS 180-4