What is actually inside a PDF after you sign it

Search for whether a signed PDF is legally binding and you get a wall of confident pages, most of them selling signing software, all of them answering a legal question. Almost none answer the mechanical one: when you draw your name on a PDF and download it, what is in the file?

We signed one and took it apart. Knowing what is actually in there tells you which documents this is fine for and which it is not — more usefully than another summary of the ESIGN Act.

Before and after

A five-page report, signed with a signature drawn by hand, then parsed object by object.

The signature, in full

Signing added exactly one thing to the page's content stream:

q
1 0 0 1 214.2 278.698 cm
183.6 0 0 44.523 0 0 cm
/Image-7098480789 Do
Q

Save the graphics state, move to a position on the page, scale to 183.6 × 44.5 points, draw an image, restore. That is the entire signature. The two image objects it refers to are 1600 × 388 pixels: one holds 1,862,400 bytes of colour — exactly three bytes per pixel — and the other holds 620,800, exactly one byte per pixel, which is the transparency mask that keeps the paper around your pen strokes see-through.

So the signature is a picture, positioned on top of the page. The document does not “know” it has been signed. Nothing in the file connects the picture to a person, a time, or the bytes of the document it sits on.

What that does and does not give you

An electronic signature of this kind is legally recognised in most places — ESIGN and UETA in the United States, eIDAS in the EU — and courts accept drawn and typed signatures routinely. The usual requirements are about conduct, not cryptography: that you meant to sign, that you agreed to do it electronically, that the signature is attached to the record, and that the record is retained. A drawn signature on a PDF can satisfy all four.

What it cannot do is prove anything by itself, and the file shows exactly why:

• It does not detect changes. A cryptographic signature stores a /ByteRange — a record of which bytes it covers — so any later edit breaks it visibly. There is no /ByteRange here. Someone can change a number on page 3 and your signature sits there looking undisturbed.
• It does not identify the signer. There is no certificate, no key, no identity of any kind in the file. The picture looks like your handwriting; that is the whole of the claim.
• It does not record when. No signing timestamp is written. The document dates are the document's, not the signature's.
• It can be lifted. This is the part worth sitting with. The signature is a plain image object inside the file, and we extracted both of ours straight out with a short script — no cracking involved, just reading the file the way any PDF reader does. Anyone you send a signed PDF to receives a clean, transparent, reusable copy of your signature.

That last point is not a flaw in any particular tool. It is true of every drawn or scanned signature on every PDF, including ones produced by expensive software, and it is true of the paper contract you posted, scanned and emailed. It is simply worth knowing before you send your signature to a stranger who asked for it.

Full rewrite, not an incremental update

Our output has one %%EOF: the document was written out fresh, and the pre-signature version is not inside it.

Desktop signing software usually works the other way, appending changes to the end and leaving the earlier version in place — which is what lets a reader show you signature history, and also what makes those files grow with every save. Both approaches are valid PDF. The practical difference: with an incremental file, the unsigned version can be recovered from the file you sent; with a full rewrite, it cannot. If that matters to you, it matters in both directions, so it is worth knowing which one you produced.

When a picture is not enough

Match the tool to the stakes. A drawn signature is genuinely fine for most of what people sign:

When the requirement is real assurance, what you need is a certificate-based digital signature — the kind that writes /Type /Sig and a /ByteRange into the file and binds your identity, the timestamp and the document's exact bytes together. That needs a certificate from an authority that has verified who you are. It is a different category of thing, not a better version of the same thing, and no browser-based tool — including ours — can produce one. We would rather say that plainly than let the word “sign” imply otherwise.

Practical notes

• A signature image is not more secure than a drawn one. Both end up as the same kind of image object. If you keep a signature PNG on your computer, treat that file the way you would treat a signed blank page. The signature generator makes one with a transparent background for exactly this workflow — which is convenient, and worth being deliberate about.
• Flattening is what you want. A signature drawn into the page content, as above, is part of the page. A signature added as an annotation can be moved or deleted in any PDF editor, sometimes accidentally.
• Send a copy, keep the original. Signing rewrites the file. Keep the unsigned document if you may need to produce it later.
• Password-protected files must be unlocked first. A PDF with an owner password cannot be modified until the protection is removed — that is what unlock PDF is for, and it needs the password.
• Signing is one pass among several. If the document also needs page numbers, a watermark or pages removed, do those before you sign — each pass rewrites the file. The PDF tools all work on the same page objects, so the order you run them in is the order the changes land.

How this was measured

The PDF was signed in a real headless Chrome, with the signature drawn using actual mouse events rather than a synthetic image, and the downloaded file was analysed with a parser written for this article: it walks the object table, decompresses every stream, and reports what it finds. One detail cost us a false conclusion first time round — the library that writes these files packs most objects into compressed object streams, so a naive search of the raw bytes reports /Annots and the document info as “missing” when they are simply compressed. They are intact; the link annotations and document metadata in the table survive signing. The parser now expands object streams before reporting, which is why those rows read the way they do.