Drawn signature vs digital certificate

A PDF is a collection of numbered objects: pages, fonts, images, and content streams — lists of drawing operators that say “set this font, move here, show this text, draw this image”. An image lives as an XObject: a dictionary with the pixel data, its colour space and, for transparency, a soft mask (/SMask) that stores the alpha channel. To put an image on a page, the page's content stream gets a few operators: save state (q), a transformation matrix that sets position and size (cm), draw the XObject (Do), restore state (Q).

That is all a drawn signature is. When PDF InkPad exports, it embeds your signature PNG as an image XObject with an SMask, embeds a subset of Noto Sans for text fields, and appends a short content stream to each edited page. Structurally the file cannot distinguish your signature from a stamp or a photograph. Anyone with an editor can move it, delete it or copy it to another document, and nothing in the file records who added it or when — the modification date in the metadata is just a field anyone can set.

A digital signature uses the PDF's form machinery. The document gets an AcroForm field of type /Sig whose value is a signature dictionary. Two entries do the work. /ByteRange lists which byte ranges of the file are covered — in practice everything except a gap reserved for the signature itself — and /Contents holds that gap: a DER-encoded CMS (PKCS#7) structure containing the signer's X.509 certificate, the hash algorithm, the hash of the covered bytes and that hash encrypted with the signer's private key. The /SubFilter says which flavour it is: adbe.pkcs7.detached for classic Acrobat signatures, ETSI.CAdES.detached for the European PAdES profile that eIDAS-qualified signatures use.

Signing therefore happens in a fixed order: the software writes the whole file with a placeholder of zeros in /Contents, hashes the bytes named in /ByteRange, has the private key sign the hash (on a smart card, a USB token, a phone app or a cloud HSM), and drops the result into the placeholder. A timestamp from an RFC 3161 authority can be embedded so the time is asserted by a third party rather than the signer's clock, and for long-term validation the certificate chain and revocation data are stored in a DSS dictionary so the signature can still be checked after the certificate expires.

The visible part is optional. A signature field may have a widget annotation with an appearance stream — an image of a handwritten signature, a name and date, a logo — but that appearance is cosmetic. The binding is between the certificate and the bytes, and a certificate signature with no visible appearance at all is just as valid.

Because the signed hash covers the file's bytes, changing a single one of them — a word, a number, a page — makes the recomputed hash differ from the signed one and the validator reports the signature as invalid. That is the property a drawn signature simply does not have: an image proves nothing about the text around it.

PDF does allow changes after signing through incremental updates: new objects are appended after the signed bytes, leaving the original range intact. This is how a second party countersigns, and how form fields can be filled after a certification signature. The first signer can restrict what is allowed with a DocMDP permission level — no changes, form filling and signing only, or annotations too — and validators flag anything beyond it. A tool that rewrites the file from scratch instead of appending, as pdf-lib does, breaks every earlier signature, which is why PDF InkPad tells you to add visual fields first and certificate signatures last.

A drawn signature is the right tool when the parties know each other and the risk is ordinary: freelance contracts, NDAs, rental paperwork, school forms, approvals inside a company. Its evidence is the email thread and the relationship, and its advantages are real — no software to install, no certificate to obtain, works on any device, and the file stays private.

A certificate signature is required when the law or the counterparty needs proof of identity and integrity that stands on its own: public tenders, court and tax filings, corporate resolutions, anything filed with a registry, contracts with strangers at a distance, and documents that must remain verifiable for years. In the EU that usually means a qualified signature from your national eID or a qualified trust service; in the US, a signature from a certificate authority on Adobe's Approved Trust List. The two can coexist: a visible signature placed with a browser tool, then a qualified signature sealing the whole file.

Open the file in Acrobat Reader: a certificate-signed document shows a blue bar at the top and a Signature Panel listing each signer, the certificate chain, whether the document changed after signing, and the timestamp. Firefox's built-in viewer, which uses pdf.js, shows a notice that the document contains a digital signature but does not validate it. macOS Preview shows nothing at all. If none of these mention a signature, the mark on the page is an image.

For a qualified European signature, the authoritative check is a validator that consults the EU Trusted Lists: the European Commission's DSS demonstration service, or national tools such as Estonia's DigiDoc4. On the command line, pdfsig from the Poppler project prints every signature field with its byte ranges, certificate subject and validation status, and pyHanko does the same in Python. Whatever the tool, look for three answers: whose certificate, whether the covered range includes the whole document, and whether anything was modified afterwards.