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 PKCS#7 structure using node-forge, and reports what it finds.

The PAdES levels

The European standard ETSI EN 319 142-1 (PAdES — PDF Advanced Electronic Signatures) defines four levels of trust depth: 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). Adobe AATL (Adobe Approved Trust List) is the de-facto private equivalent for non-EU contexts; the EUTL (EU Trusted List) is the European public-CA registry. None of these are validated by this tool — the goal here is to inspect the raw structure, not to certify legal validity.

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 clever attack: a malicious editor adds new content in a place the ByteRange explicitly excludes (e.g. annotation layers added after signing). Adobe Reader catches this as "Signature is valid, but document has been modified" — but plenty of casual viewers don't surface that distinction.

ASEAN context — IMDA, MyDigital ID, NIK

Singapore's National Digital Identity (Singpass) supports digital signatures via the Sign with Singpass feature, backed by GovTech's certificate infrastructure. Malaysia's MyDigital ID and earlier MSC Trustgate certificates underpin domestic digital-signature use. Indonesia's electronic ID (NIK)-linked PSrE (Penyelenggara Sertifikasi Elektronik) providers issue local digital certificates. Cross-border, an EU AATL-listed certificate is usually accepted by ASEAN PDF readers, but legal admissibility varies — Singapore's Electronic Transactions Act 2010 explicitly recognises foreign electronic signatures, while some ASEAN jurisdictions require a locally-issued certificate for legal binding. Always check the contract's jurisdiction clause before signing important documents.