Verify PDF Digital Signature

What a PDF digital signature really is

When a document is digitally signed, the writing application reserves a block of empty space inside the PDF and records a /ByteRange that names every byte of the file except that block. It hashes those bytes, wraps the hash in a PKCS#7 (CMS) structure together with the signer's certificate, signs it with the signer's private key, and writes the result into the reserved space.

Verification reverses that process exactly. This page reads the same byte range, computes the same hash with the same algorithm, and compares it with the value that was signed. If a single byte of the covered content has changed — one character of text, one pixel of an image, one entry in the page tree — the hashes will not match and the signature is reported as invalid.

Every check this tool performs

Each signature in the document is examined independently, and each result is shown as a separate labelled check so nothing is hidden behind a single green tick:

• Signed byte range — confirms the signature starts at byte zero and that the unsigned gap wraps the signature container exactly, so no content can be smuggled into the gap.
• Document integrity — recomputes the SHA-1, SHA-256, SHA-384, or SHA-512 digest of the covered bytes and compares it with the signed message-digest attribute.
• Signature authenticity — verifies the RSA PKCS#1 v1.5, RSASSA-PSS, ECDSA, or Ed25519 signature against the public key inside the signer certificate.
• Certificate binding — where a signed ESS signing-certificate attribute is present, checks its hash so the certificate cannot be swapped for another one.
• Certificate validity — reports whether the certificate was inside its validity window at the moment of signing, not just today.
• Certificate chain — rebuilds the chain from the embedded certificates and cryptographically verifies every issuer signature, link by link, up to the root.
• Trusted timestamp — decodes any RFC 3161 token, checks its imprint against the signature value, and verifies the time-stamping authority's own signature.
• Document coverage — determines whether the signature covers the whole file or only an earlier revision, and describes what was appended afterwards.
• Algorithm strength — flags legacy SHA-1 and MD5 based signatures that should no longer be treated as strong evidence.

Multiple signatures and incremental revisions

PDFs can be signed more than once. Each new signature is written as an incremental update appended to the end of the file, which means an earlier signature only covers the revision that existed when it was applied. This is normal and legitimate — but it also means an earlier signature cannot vouch for anything added later.

The tool makes that explicit. For every signature it reports revision X of Y, whether the signature covers the entire file as it stands now, and, when it does not, what kind of objects were appended afterwards. If the later revision only contains signature-related objects such as another signature, a document timestamp, or validation data, you are told so. If ordinary page content or annotations were added, that is called out clearly as unprotected content.

Certification signatures and what changes they allow

A certification signature (a DocMDP signature) is the first signature applied by the document author and it declares what anyone else may do to the file afterwards. The tool reads the transform parameters and reports the permission level in plain language: no changes allowed, form filling and signatures allowed, or form filling, signatures and annotations allowed.

Approval signatures — the ordinary kind added by each subsequent signer — are labelled separately, as are document timestamps, so you can see at a glance how the document was assembled.

Why a trusted timestamp matters

The signing time written into the signature dictionary comes from the signer's own computer clock. It can be wrong by accident or set deliberately, and nothing prevents that. An RFC 3161 timestamp is different: an independent time-stamping authority signs a hash of the signature at a known moment, producing evidence of time that does not depend on the signer.

When a timestamp is present, the tool decodes the TSTInfo structure, confirms the imprint really covers this signature, verifies the authority's signature, and shows the authority name, policy, serial number and stated accuracy. When no timestamp is present, that is reported as a warning rather than quietly ignored, because it changes how much the recorded signing time is worth.

The certificate chain, honestly explained

A signature is only as meaningful as the certificate behind it. The tool collects every certificate embedded in the signature, matches each subject to the next issuer, and verifies each issuer signature with real cryptography rather than just comparing names. The result is displayed as a chain from the signer up to the root, with the key algorithm, key size, validity window, key usage and SHA-256 fingerprint of every link.

There is one thing no web page can do: read the trust store of your operating system or of Adobe Acrobat. Rather than pretend otherwise, this tool separates the two questions. It tells you whether the chain is mathematically sound and where it terminates, and then lets you add the root certificate you actually trust. Drop in that root and the verdict is recalculated against it immediately — still entirely in your browser.

Long-term validation data

PAdES long-term signatures store revocation evidence — OCSP responses and CRLs — inside the document itself in a Document Security Store, so the signature can still be validated years later when the original responders are gone. The tool reports whether that data is present, along with any revocation URLs published in the certificates.

Live revocation checking is deliberately not attempted. A browser cannot contact an OCSP responder or CRL endpoint directly because of cross-origin restrictions, and pretending to check revocation would be worse than saying plainly that it was not checked.

Formats and algorithms supported

The verifier handles the signature sub-filters found in real documents: adbe.pkcs7.detached (the standard Acrobat format), ETSI.CAdES.detached (PAdES, used across the EU for eIDAS signatures), ETSI.RFC3161 document timestamps, the legacy adbe.pkcs7.sha1, and the deprecated adbe.x509.rsa_sha1 raw format.

On the cryptographic side it covers RSA PKCS#1 v1.5, RSASSA-PSS with its salt parameters, ECDSA over P-256, P-384 and P-521, and Ed25519 where the browser supports it, each combined with SHA-1, SHA-256, SHA-384 or SHA-512. Where a document uses something a browser genuinely cannot compute, such as DSA or a SHA-3 digest, the tool says so instead of guessing.

Privacy by construction, not by promise

Signed PDFs are usually the most sensitive documents an organisation handles: contracts, invoices, tax filings, medical records, court submissions. Uploading them to an unknown server just to answer the question "is this genuine?" defeats the purpose.

This page never does that. The file is read with the browser File API, parsed by JavaScript running on your machine, and verified with the Web Crypto API built into the browser itself — the same engine that secures HTTPS. The heavy work runs in a Web Worker so the page stays responsive on large files. No third-party cryptography service is contacted, and closing the tab discards everything.

Verification reports you can file

Professionals rarely need only a screen result. Download a formatted PDF report containing the verdict, the document facts, every check with its explanation, the signer details, the certificate chain with fingerprints, and the technical parameters — suitable for attaching to a case file or a compliance record.

A JSON report is also available with the complete structured result, which is useful if you want to archive verifications or feed them into another system. Both reports are generated on your device.

Reading the result correctly

A green verdict means the covered bytes are unchanged and the signature matches the certificate presented. An amber verdict means the cryptography is sound but something needs your judgement — an expired certificate, a missing timestamp, content appended after signing, or a chain that stops short of a root. A red verdict means a cryptographic check actually failed, and the document should not be relied on.

No verdict, of any colour, tells you that the person named in the certificate is who they claim to be in the real world. That depends on the certificate authority that issued it and on your own policy. The tool gives you every fact needed to make that call and is explicit about where its knowledge ends.

Works on desktop, tablet, and phone

The same verification runs on any modern browser on Windows, macOS, Linux, Android, or iOS. On a phone, tap the upload area and choose the PDF from your files app. Web Crypto requires a secure context, so the page must be opened over HTTPS — which it always is on mypdf.guru.

Related things you may want to do

If you need to place a visible signature image on a document, use the Sign PDF tool — note that a drawn or typed signature is a visual mark, not a cryptographic one, so it cannot be verified here. To protect a finished document with a password, use the PDF Password Adder, and to remove one you already know, use the PDF Password Remover. Remember that editing, compressing, or merging a signed PDF will break its existing digital signatures, because those operations rewrite the bytes the signature protects.