PDF signature: pasted image or PAdES signature?

Pasted signature image or PAdES signature: integrity, tamper detection, certificate, timestamp and third-party checks. A clear comparison for product teams.

Published Oct 3, 2026 · 8 min read

A signature image pasted into a PDF is just a drawing: it can be copied in two clicks and does nothing to protect the document. A PAdES signature is a cryptographic signature built into the file: it covers the whole document, exposes any later change, carries the signer’s certificate and can be checked in an ordinary PDF reader. For a product that sends contracts, the sound approach is to use both: a visual mark people recognise, and a PAdES seal that provides the technical proof.

The short answer

Many software vendors started simply. The signer draws a signature in the browser, the server stamps it as a PNG on the last page, and the PDF goes out by email. The result looks like a signed document. Technically, it is an edited PDF with an image added.

The useful question for your product team is therefore: what can the file itself prove? With an image alone, almost nothing. With PAdES, you can show that the document has not changed since it was signed, and which certificate signed it.

What a signature image is

A signature image is a graphic object placed on a page, much like a logo. The PDF keeps no link between that image and the text around it.

• It is visual only: it shows that someone drew or uploaded a stroke, and says nothing about the content they approved.
• It can be copied: anyone can extract the image from a PDF they received and paste it onto another document.
• It does not protect integrity: an amount, a date or a clause can be edited afterwards and the signature still looks exactly the same.
• It carries no verifiable identity: no certificate, no key, nothing a third party could check.

Take a quote generated in a CRM. The customer signs, the image is stamped, the PDF is archived. Six months later, a version of the quote turns up with a different discount. If both files carry the same image, nothing in the PDF tells you which one is the original.

What a PAdES signature adds

PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 142) is the standard format for embedding a cryptographic signature in a PDF. Our dedicated guide covers the technical chain; here is what changes in practice for your product. PAdES: inside a signed PDF

• Integrity of the whole document: a digest (for example SHA-256) is computed over the signed content of the PDF and then signed with a private key.
• Tamper detection: if a single byte of the signed range changes, verification fails and the PDF reader says so.
• Signer certificate: the X.509 certificate used to sign is embedded in the file, with the identity it claims and its issuer.
• Optional RFC 3161 timestamp: when a timestamp authority is connected, a token dates the signature in a verifiable way.
• Verification outside your application: Adobe Acrobat Reader and other readers display the signature status, with no account or access to your platform.

The last point matters most. Proof that exists only in your database depends on your service being there. A PAdES signature travels with the file, so your customer, their auditor or their lawyer can check it on their own.

What the signature panel shows

Open a PAdES-signed PDF in Adobe Acrobat Reader: a banner appears above the document and the Signatures panel lists each signature. For every one, the reader answers two separate questions.

1. Has the document been modified since it was signed? This is the integrity check. A “no” means the signed content is intact.
2. Is the signer’s identity recognised? The reader follows the certificate chain to an authority it knows. If it finds none, it reports an unknown or unverified identity.

With a self-signed test certificate, like the one used in the Khatm demo and sandbox, the first answer is fine and the second shows a warning. That is expected: the certificate does not chain to any authority in the reader’s trust store. The warning does not mean the file was tampered with. A pasted image, by contrast, produces no panel at all, because there is nothing to verify. Self-signed or independently trusted?

Side-by-side comparison

The last row explains why images are still common: they are quick to build. The real cost shows up later, at the first dispute or the first customer security review that asks how the document is protected.

When the visual mark still matters

Dropping the image does not mean dropping the visual. Signers, HR teams and customers expect to see a signature where it belongs: at the bottom of an employment contract, next to the name on a purchase order, on every page of a mandate. A document that shows nothing feels unfinished, even when it is properly signed.

PAdES allows for this. A signature can have a visible appearance placed in a signature field on the page. The visual serves the human reader; the cryptographic signature serves the proof. Both live in the same file.

Evidence beyond the PDF

A PAdES signature proves document integrity and the certificate used. It does not tell the story of the process: who received the link, when the document was opened, in what order signers acted, whether someone declined. That takes process evidence.

• A timestamped activity log for each signature request (sent, opened, signed, declined, cancelled).
• A PDF evidence report that a non-technical reader can follow.
• JSON evidence your software or archive can process.
• SHA-256 digests that tie this evidence to the signed PDF.

The legal effect of an electronic signature depends on the certificate, how signers are identified and the context. This guide draws no conclusion about validity in any country; check that point with your legal counsel.

Moving your product from images to PAdES

1. List the documents involved: HR contracts, customer onboarding, quotes, mandates. Flag the ones currently signed by stamping an image.
2. Keep the visual placement: signature fields replace the areas where you paste the image today.
3. Test the full journey in the demo or the API sandbox, then open the signed PDF in Adobe Acrobat Reader and read the signature panel.
4. Fetch the signed PDF and the evidence through the API and connect them to your archive.
5. Prepare production: certificate from your PKI, HSM or trust service provider, signer identity, timestamping, retention period.

Once a request is completed, three artifacts are available in the sandbox:

# Signed PDF (PAdES)
curl -H "Authorization: Bearer $KHATM_TEST_KEY" \
  -o contrat-signe.pdf \
  "$KHATM_API_BASE/v1/signature-requests/$REQUEST_ID/artifacts/signed-pdf"

# Evidence report (PDF) and evidence (JSON)
curl -H "Authorization: Bearer $KHATM_TEST_KEY" \
  -o preuves.pdf \
  "$KHATM_API_BASE/v1/signature-requests/$REQUEST_ID/artifacts/evidence.pdf"
curl -H "Authorization: Bearer $KHATM_TEST_KEY" \
  -o preuves.json \
  "$KHATM_API_BASE/v1/signature-requests/$REQUEST_ID/artifacts/evidence.json"

How Khatm signs your PDFs

Khatm provides PDF signing built into your software, under your brand, in Arabic, French and English. Every PDF signed with Khatm carries a PAdES signature, whether the request starts on the platform or through API v1.

• Demo and sandbox: PAdES signature with a self-signed test certificate. The identity warning in the PDF reader is expected. Content is deleted 10 days after the PDF upload.
• Production: signature with the certificate from your PKI, HSM or trust service provider, and RFC 3161 timestamps when that provider supplies them. Khatm does not issue certificates and is not a qualified trust service provider.
• In every case: PDFs encrypted at rest, activity log, PDF evidence report and JSON evidence.

Test in the sandbox; we guide you all the way to production. Start with the demo, read the documentation, then prepare production with Khatm implementation. Try the demo API documentation Implementation

General information, not legal advice. Confirm the requirements for your transaction with the appropriate adviser or receiving authority.