Drawing Your Name on a PDF Is Not a Digital Signature
Our Sign PDF tool embeds a PNG and draws it on the page. That is what almost every free "PDF signature" tool does, and under US and EU law it is usually still a valid electronic signature — but it proves nothing about whether the document changed afterward. Here is the mechanism a real PDF signature uses, and the exact legal line between the two.
Here is the entire signing operation in our Sign PDF tool, lifted from the source:
const pngImage = await pdf.embedPng(sigBytes);
pdfPage.drawImage(pngImage, { x, y, width: sigW, height: sigH });
const bytes = new Uint8Array(await pdf.save());Embed a PNG, draw it on a page, save. That is it. No key, no certificate, no hash of the document. This is what almost every free “sign a PDF online” tool does, ours included, and it is worth saying plainly rather than letting the word “sign” imply something it does not.
It is also — and this surprises people in the other direction — usually legally sufficient. The two facts fit together once you notice that “electronic signature” and “digital signature” are different words for different things, and only one of them is about cryptography.
The legal layer: intent, not math
In the United States, 15 U.S.C. §7001(a), the ESIGN Act, says a signature “may not be denied legal effect, validity, or enforceability solely because it is in electronic form.” And §7006(5) defines the term:
The term “electronic signature” means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.
An electronic sound. A symbol. The operative words are intent to sign — the legal test is about what the signer meant, not about how the bytes were produced. A PNG of your handwriting, placed on a contract you meant to sign, satisfies this.
The EU’s eIDAS Regulation is structured the same way at the base level. Article 3(10) defines an electronic signature as “data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign,” and Article 25(1) says such a signature “shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures.”
So for ordinary agreements in most jurisdictions, the stamp is a signature. What it is not is evidence.
What the stamp cannot do
eIDAS defines two stronger tiers, and their requirements are a precise inventory of what an image lacks. Article 26 says an advanced electronic signature must meet four requirements:
(a) it is uniquely linked to the signatory; (b) it is capable of identifying the signatory; (c) it is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control; and (d) it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable.
A drawn PNG fails all four, and (d) is the one that matters in a dispute. Once the image is on the page:
- Anyone with a PDF editor can move it, delete it, or copy it onto a different document. It is a picture; nothing binds it to this page or this text.
- Anyone can edit the paragraph above it — change a number, a date, a party — and the signature image will sit there looking exactly as valid as before.
- Nothing in the file records who applied it, when, or from what.
The document carries no way to answer “was this altered after signing?” — and that question, not “did they sign?”, is what actually gets litigated.
A qualified electronic signature — Article 3(12): an advanced signature “created by a qualified electronic signature creation device” and based on a “qualified certificate” — gets the strongest possible statement in Article 25(2): “A qualified electronic signature shall have the equivalent legal effect of a handwritten signature.” That sentence is the reason the tiers exist.
What a real PDF digital signature does
The mechanism has been in the PDF specification since PDF 1.3. From ISO 32000-1 §12.8.1:
Signatures shall be created by computing a digest of the data (or part of the data) in a document, and storing the digest in the document. To verify the signature, the digest shall be re-computed and compared with the one stored in the document. Differences in the digest values indicate that modifications have been made since the document was signed.
That last sentence is requirement (d), implemented. The details are worth knowing because they explain the shape of a signed PDF:
The ByteRange covers nearly the whole file. The spec: “A byte range digest shall be computed over a range of bytes in the file, that shall be indicated by the ByteRange entry in the signature dictionary. This range should be the entire file, including the signature dictionary but excluding the signature value itself (the Contents entry).” It is an array of (offset, length) pairs — two of them, one before and one after the signature bytes — because a digest cannot cover the space it is going to be written into. If you have ever seen /ByteRange [0 840 960 12043] while poking at a signed PDF, that hole in the middle is /Contents.
The signature value is a PKCS#7 blob. /Contents holds the signed digest plus, typically, the signer’s certificate chain — which is what turns “this file has not changed” into “this file has not changed and here is who signed it.”
Later edits are appended, not rewritten. “If a signed document is modified and saved by incremental update, the data corresponding to the byte range of the original signature is preserved. Therefore, if the signature is valid, it is possible to recreate the state of the document as it existed at the time of signing.” This is why a properly signed PDF can be signed again by a second party without breaking the first signature, and why a viewer can show you “the version as signed by A” versus “the current version.”
A certification signature can lock the document. At most one per file, carrying a DocMDP transform that declares which later changes (none, form-filling only, form-filling and annotations) keep the signature valid.
Trust is a separate problem from integrity
The cryptography proves the bytes did not change. It says nothing about who signed unless the certificate means something to the verifier — which is why the certificate chain is the expensive part of the system, not the signing.
Generating a keypair is free and takes a second. Getting a certificate that a stranger’s copy of Acrobat will show a green check for means enrolling with a CA that Adobe or the EU trust list already recognizes, proving your identity to them, and paying for it. A self-signed certificate produces a mathematically perfect signature that every recipient sees as untrusted, which is correct behavior, not a bug. If you want to see what is actually inside one of these, paste a certificate into the X.509 decoder — how to read an X.509 certificate walks the fields — and the CSR generator is the first step of enrollment (why the private key never leaves your browser explains what a CSR does and does not contain).
So which do you need?
| Situation | A drawn image is | Why |
|---|---|---|
| NDA, offer letter, vendor agreement between parties who trust each other | Usually fine | ESIGN/eIDAS recognize intent; disputes are rare and resolved on other evidence |
| A document that will be forwarded, archived, or relied on by a third party | Not enough | Nothing detects a later edit; the third party has no way to check |
| Anything where you must prove when it was signed | Not enough | Needs a trusted timestamp, which the image has no place to carry |
| Regulated filings, EU cross-border, high-value contracts | Not enough | These specify advanced or qualified signatures explicitly |
| A document you also need to keep other people from editing | Not enough | That is a certification signature with DocMDP, not a picture |
What our tool does, stated exactly
Sign PDF rasterizes your signature — drawn with a pointer, typed in a handwriting font, or uploaded as an image — to a PNG, embeds it, and draws it at the page and position you choose. Everything happens in your browser; the PDF is never uploaded. Three things follow from that, and you should know all three:
- It produces an electronic signature, never a digital one. It is built on pdf-lib 1.17.1, whose feature list does not include signing at all. We could not add a cryptographic signature here without key material and a certificate you actually trust, and we are not going to fake the appearance of one.
- It re-saves the whole file. The final call is
pdf.save(), a complete re-serialization rather than an incremental update. If the PDF you feed it already carries a digital signature, that signature will be invalidated. Sign last, or do not use this tool on already-signed documents. - The stamp is page content, not a form field. It sits in the page’s content stream like any other image — which also means it does not cover, remove, or protect anything underneath it. If you are stamping over text you want gone, see black boxes don’t redact PDFs; PDF redact removes the text layer, and PDF metadata shows you what else the file is still carrying.
If you only want the signature graphic itself — for a document, an email footer, or a form — the signature generator exports it as a transparent PNG or a real SVG path, without touching a PDF at all.
The short version
| The assumption | What is actually true |
|---|---|
| ”A drawn signature isn’t legally binding” | ESIGN §7006(5) turns on intent to sign; a drawn image usually qualifies |
| ”A drawn signature is a digital signature” | No cryptography is involved; nothing detects a later change |
| ”Digital signature = the image looks official” | It is a digest over a ByteRange covering the file except /Contents |
| ”Signing again breaks the first signature” | Incremental updates preserve each earlier signed state |
| ”I generated a certificate, so it’ll show as valid” | Self-signed verifies mathematically and displays as untrusted, correctly |
| ”Any e-signature satisfies EU requirements” | Article 26 requires change detection; only a qualified signature equals a handwritten one |