Skip to main content
Orilami

PDF Signature Checker: before and after

An illustration with sample files; your own files show their own results.

BeforeAll three show as “signed”

  • Contract: viewer says signed

  • Agreement: viewer says signed

  • Invoice: viewer says signed

AfterWhat the audit actually finds

  • Total changed after signing

  • Shadow attack found

  • Signature intact

PDF Signature Checker — Was a Signed PDF Changed After Signing?

A byte-level audit for digitally signed PDFs. It parses the raw file, not a viewer's rendered model, to check what each signature actually covers, decode the CMS/PKCS#7 cryptography, walk the revision chain and detect shadow attacks and visual overlays. Everything runs in a Web Worker in your browser; the file never leaves your device and no CA, OCSP or timestamp server is contacted.

What it verifies

  • ByteRange integrity: the [o1 l1 o2 l2] window must start at byte 0 and leave a gap only for /Contents. Extra ByteRange/Contents injections and trailing unsigned data are flagged.
  • CMS / PKCS#7: the DER SignerInfo is decoded and verified with WebCrypto (RSASSA-PKCS1-v1_5, RSA-PSS, ECDSA over SHA-256/384/512) against the exact signed bytes.
  • Certificates & PAdES tier: the chain, key usage and validity windows are shown, and the profile (B-B / B-T / B-LT / B-LTA) is classified from timestamps and the DSS.
  • Incremental updates: every %%EOF revision is diffed to separate allowed additions (a later signature, a DSS) from mutations that redefine signed objects.
  • Shadow attacks: Hide, Replace and Hide-and-Replace vectors, such as a swapped Catalog or Pages tree, mutated AcroForm/XFA, redefined fonts, or an opaque overlay over signed content.

Trust anchors and revocation

Because the tool is strictly local, it does not validate certificates against AATL / eIDAS trust lists or run live OCSP/CRL checks; both need network calls and large trust stores. Embedded revocation data (DSS/VRI) and timestamp tokens are decoded and shown but reported as not validated. For legal non-repudiation, confirm trust and revocation in a validator with network access.

Frequently asked questions

What is a shadow attack on a signed PDF?
Content is hidden in the document before signing, then revealed by an edit that stays inside the signed byte ranges, so the signature still validates while the visible page says something different. The audit compares what the signature covers with what a viewer renders, which exposes the swap.
A PDF reader says the signature is valid. Why run this?
A reader answers one question: does the cryptography check out. It will not say that the signature covers only part of the file, that a later update changed the visible page, or which revision you are looking at. This audit reads out those gaps.
What does the ByteRange check prove?
The ByteRange shows exactly which bytes the signature protects. A legitimate signature covers the whole document except its own container; gaps mean parts of the file can change without breaking the signature.
Does it check whether the signing certificate was revoked?
No. Revocation checking needs an OCSP or CRL request, which would send data about your document off your machine. The tool validates the signature and certificate chain offline and states that revocation was not fetched.
What is a PAdES tier?
PAdES is the European profile for PDF signatures, with levels (B-B, B-T, B-LT, B-LTA) that add a trusted timestamp and long-term validation data. The audit reports which tier a signature reaches, which sets how long it stays verifiable.
Is my PDF uploaded anywhere?
No. Parsing, hashing and signature verification run in a Web Worker in your browser. The file never leaves your device and no external server is contacted.
What does “modified after signing” mean?
The signatures verify, but a later incremental update changed protected structure (the Catalog, a page, a form field, or an added opaque overlay) in a way that changes what the document shows. That is the classic shadow-attack pattern.
Why isn’t the certificate marked trusted?
Trust-anchor checks against AATL/eIDAS and OCSP/CRL revocation need network access and bundled trust stores, which would break the local-only privacy model. The chain is decoded and shown; trust and revocation are reported as not validated.
Which signature algorithms are verified?
RSASSA-PKCS1-v1_5, RSA-PSS and ECDSA over SHA-256/384/512, via WebCrypto. Legacy adbe.x509.rsa.sha1 signatures are decoded but not cryptographically verified.
Can it export a report?
Yes. The full JSON report (verdict, per-signature result, certificate chain, timestamps, revision chain and every tamper finding with severity) downloads in one click.
More questions about Orilami

PDF Signature Checker at a glance

Key facts about PDF Signature Checker: where it runs, what it costs, what it accepts and produces, and its limits.
Where it runsEntirely in your browser. Files are never uploaded.
Cost90 tokens per file (about $0.90 at the base rate)
AcceptsA signed PDF
ProducesA byte-level audit: ByteRange coverage, CMS signature validation, PAdES tier, document revision history, and shadow-attack findings.
BatchOne at a time.
Account neededOnly to spend tokens. Browsing and previewing are free.
What it does not doCryptography is checked offline, so certificate revocation status (OCSP/CRL) is not fetched: nothing is sent to a network.