PDF Signature Checker

A digital signature inside a PDF is a piece of cryptographic data embedded in the PDF structure that proves two things: (1) the document hasn't been modified since it was signed, and (2) the signer was in possession of a specific private key at the time of signing. It does NOT prove the signer's real-world identity unless you also trust the certificate authority that issued that signer's certificate. The distinction between cryptographic validity and legal validity is what most users don't realise — and it's the source of every "but this PDF is signed!" misunderstanding in real-world contract disputes.

What the PDF actually contains

Inside a signed PDF, the signature lives in a dictionary referenced by the document's AcroForm. The key fields are /ByteRange (which bytes of the PDF are covered by the signature — typically everything except the signature blob itself), /Contents (a hex-encoded PKCS#7/CMS structure containing the actual cryptographic signature plus the signer's certificate), and /Filter + /SubFilter (which signature handler created the signature — most commonly adbe.pkcs7.detached for Adobe-flavoured signatures). The tool above reads these fields directly from the file bytes, parses the CMS structure with node-forge, recomputes the hash of the covered bytes with Web Crypto, and verifies the signature with the signer certificate's public key.

The PAdES levels

The European standard ETSI EN 319 142-1 V1.1.1 (April 2016) (PAdES — PDF Advanced Electronic Signatures) defines four baseline levels: B-B (basic — proves "someone with this key signed it"), B-T (basic + trusted timestamp from a TSA — proves "signed before this date"), B-LT (long-term — embeds all certificate chain info needed for future validation), and B-LTA (long-term with archive timestamp — for signatures that need to remain verifiable decades into the future). Trust lists — Adobe's AATL, the EU Trusted Lists — decide whether a certificate is trusted at all. None of that is checked here: this tool proves that a key signed these bytes, not that the key belongs to someone you should trust.

The byte-range trick — why "signed-then-edited" is detectable

The /ByteRange entry tells the verifier exactly which byte positions of the PDF are covered. Typically it's the whole file MINUS the bytes of the signature blob itself. The verifier hashes those bytes, then checks the hash against what the signature claims. If anyone modifies any byte in the covered range — including just adding a single space — the hash differs and the signature is invalid. The subtler case: new content appended after signing, as an incremental update. The original signature still verifies, because the bytes it covers are unchanged — but it no longer covers the end of the file. This tool reports exactly that, with the number of uncovered bytes.

ASEAN context — Singpass, MyDigital ID, PSrE

Singapore's national digital identity, Singpass, offers Sign with Singpass for signing documents digitally; Malaysia has MyDigital ID; in Indonesia, licensed certification providers (PSrE, Penyelenggara Sertifikasi Elektronik) issue signing certificates. Which certificates a court or counterparty will accept is a legal question that varies by country and by contract, and nothing in a PDF's bytes answers it — check the contract's governing-law clause before relying on a signature for anything important.