Verify a sealed PDF.

Drop a PDF here. The verifier extracts the XMP block, recomputes the self-referential document hash, queries chain.epochcoreqcs.com/v1/verify, and reports every gate result individually. If anything fails, the reason is named explicitly — not "something went wrong".

Built first for IP firms — same substrate serves pharma submissions, financial filings, healthcare records, source-document authentication, and M&A diligence.

Independent · Live · No login

Drop a PDF to verify

or click to choose · up to 32 MB · Your file is processed in this request and not retained.

Parsing XMP · zeroing hash field · recomputing SHA-256 · querying chain.epochcoreqcs.com …

No sealed PDF handy? Try our example →

What the verifier checks

Five gates. Each one is named. Each one tells you why if it fails.

Verification is not a single "valid / invalid" boolean. It's five independent checks; the document can pass some and fail others, and the answer matters either way.

1.  Watermark detected.
    The PDF contains an XMP block under the
    epochcore/proof-watermark/v2 schema
    (v1 receipts from earlier surface versions are also accepted).

2.  Document integrity.
    The self-referential watermarked_doc_hash field, when
    zeroed and the bytes re-hashed, matches what the field claims.
    PASS means the file is byte-exact since sealing.

3.  Chain anchor.
    chain.epochcoreqcs.com/v1/verify?hash=<seal_full_hash> returns
    a directive with chain_link_ok=true.

4.  Signatures present.
    The chain entry is dual-signed on chain by Ed25519
    (FIPS 186-5) and ML-DSA-87 (FIPS 204). The PDF's
    signature_algorithms field declares the same
    pair — no schema-vs-chain drift.

5.  Original-hash consistency.
    We cross-check the document's original hash (claimed in XMP)
    against the same hash recorded in the chain directive's subject
    line, so the metadata can't be edited without breaking
    verification.