Inspection status
{{ values.summary_value }}
{{ values.summary_line }}
{{ badge.label }}{{ badge.value }}
Check a local file or a synthetic example. Nothing is uploaded.
{{ selectedFile ? 'Local PDF selected' : 'Drop one PDF here' }}
{{ fileStatus }}
Leave blank for the current inspection time; changing it reinspects the selected PDF.
SignatureOrigin / objectIntegrityCoverageSigned revision bytesCurrent file bytesLater uncovered bytesCertificate datesSigner trustNext stepCopy
{{ resultsReady ? 'No current reachable signature values were found.' : values.summary_line }}
{{ row.signature }}{{ row.origin }} · {{ values.report.signatures[index].reference }}{{ row.integrity }}{{ row.coverage }}{{ row.revision_bytes.toLocaleString('en-US') }}{{ row.current_bytes.toLocaleString('en-US') }}{{ row.later_bytes.toLocaleString('en-US') }}{{ row.certificate_dates }}{{ row.trust }}{{ row.next_step }}
No signature byte ranges are available to plot.

The revision map renderer is unavailable.

SignatureFieldRecorded valueCopy
No signer certificate was parsed for this result.
{{ row.signature }}{{ row.field }}{{ row.value }}

Similar tools

A signature visible on a PDF page may be a typed name, a drawing or a scanned image. A certificate-based digital signature adds cryptographic evidence tied to the document's file bytes. It can exist without a visible mark, and a convincing-looking signature image does not show that this evidence exists.

When a signed quotation, approval or contract arrives, the first useful distinction is between the content you can see and the bytes that were signed. Signing software calculates a digest, a fixed-length value derived from those bytes, and creates a signature using a private key. Verification uses the corresponding public key, normally carried in a certificate, to check the cryptographic relationship. An intact result concerns that relationship; confidence in the certificate's owner requires further evidence.

PDFs can retain earlier versions inside the same file. An incremental update appends new objects and document references while leaving the previous bytes in place. A later approval, form change or other update can therefore coexist with an intact signature on an earlier revision. The current document may display changes that the earlier signature does not cover. Each signature needs to be considered against its own signed revision.

Dates also describe different facts. Confusing a certificate's lifetime with the time a document was signed can make an otherwise useful inspection misleading.

Certificate validity period
The certificate's stated start and end dates. Comparing a chosen instant with this interval answers a date question; it does not establish that the certificate was trusted or had not been withdrawn by its issuer, also called revocation.
Claimed signing time
A time recorded by the signer. Even when it is protected as part of a signature, the clock value is not independently established merely because the signature matches.
Trusted timestamp
Evidence from a timestamp authority that particular data existed by a stated time. The timestamp and its authority require their own verification.

A certificate's subject name, issuer and fingerprint, a digest used to distinguish the certificate, help identify the evidence being examined. They do not, by themselves, prove who controlled the signing key. Trust can depend on a checked chain of certificates leading to an authority or key the recipient already accepts. Before relying on a signed document, the relevant questions include the signed bytes, later revisions, certificate trust and any permissions governing subsequent changes. Preserving the original PDF keeps that evidence available; printing a fresh PDF or rebuilding the document can change its signed byte sequence.

How to Use This Tool:

Start with the original, unencrypted PDF. Inspection runs locally and starts when you select a file.

  1. Choose Browse PDF or drop one PDF of up to 10 MiB onto the file area. To try the workflow first, select Intact signed example and choose Use sample.
  2. Open Advanced only if you need a particular Date reference (UTC). Leave it blank to use inspection time. Entered dates are treated as UTC, and changing the reference reinspects the selected PDF.
  3. Read Signature checks after inspection finishes. Check each Integrity finding together with Coverage and Later uncovered bytes.
    If Secure context required appears, use a supported secure browser context. No integrity check ran. After a loading or file-reading failure is resolved, choose Retry inspection or select the file again.
  4. Retain the evidence you need for follow-up. The tables support CSV and DOCX reports, while Download JSON in Signature checks provides a metadata report. Use the reported Next step to decide whether to obtain another source copy, investigate later changes or establish signer trust separately.

Interpreting Results:

A completed inspection can contain intact, failed, unsupported or unchecked signatures. The headline summarizes the findings; each signature's row gives the evidence needed to interpret it.

Finding Meaning and useful follow-up
Signed bytes intact The supported cryptographic checks passed for the indicated signed revision. Check its coverage before relying on the current document.
Integrity failed The covered-byte digest or cryptographic signature did not match. Obtain an intact source copy and investigate the failure.
Invalid CMS The embedded Cryptographic Message Syntax (CMS) signature data could not satisfy the required structural or consistency checks. This finding alone does not identify an edit to the document's content.
Unsupported profile The signature falls outside the supported format, signer arrangement or algorithm. Use a verifier that supports the reported profile.
Limit reached A per-signature resource bound prevented the check. The row provides no successful integrity finding.

Current revision means the declared signed revision reaches the current file's end, with the signature-value exclusion described below. Older revision; later bytes uncovered means bytes follow that revision. Even alongside Signed bytes intact, those later bytes need separate review. For multiple signatures, the summary's Later uncovered bytes badge shows the largest individual uncovered amount, not a sum across signatures.

The Revision map places each signature's declared prefix, excluded signature value, declared suffix and any later uncovered bytes on the current file's byte scale. These are byte positions, not pages or a percentage of trustworthy content. A map can also accompany failed or unsupported integrity findings. Its CSV contains the plotted segment lengths, and its image exports preserve the visual map.

Certificate evidence records the matched signer's subject, issuer, serial number, dates and SHA-256 fingerprint. That fingerprint identifies the embedded certificate, not the whole PDF. Signer trust remains Not evaluated. Compare the certificate evidence through a suitable trust-verification process before treating a recorded name as an established identity.

No reachable signatures means a successfully parsed PDF has no signature values reachable through its current signature fields or certification reference. It does not establish that the file was never signed. A malformed PDF, unsupported structure, cancellation, timeout or unavailable browser capability has a separate outcome and must not be read as either an unsigned document or a successful integrity check.

Technical Details:

A PDF byte-range signature binds a cryptographic signature to selected original file bytes. The embedded signature value occupies a reserved gap so that writing it into the file does not alter the bytes used for the document digest. Later incremental updates can extend the file beyond the signed revision without changing those earlier bytes.

Two signed byte ranges surround the excluded signature value; later bytes lie beyond the signed revision.
Schematic byte layout, not to scale. The signature-value gap belongs to the signed revision's length but is excluded from its digest.

Formula Core: byte coverage

The supported /ByteRange [0 a b c] describes two ranges. Here, a is the first range's length, b is the second range's starting offset, c is its length and N is the current file length. Every value is an integer number of bytes, and offsets start at zero.

The covered input joins the bytes from offset zero up to, but excluding, a with the bytes from b up to, but excluding, b + c. The following quantities distinguish the revision length from the amount actually hashed.

R=b+c H=a+c G=b−a U=N−R

R is Signed revision bytes, H is the number of covered bytes hashed, G is the excluded signature-value span and U is Later uncovered bytes. The revision length includes the excluded span. A zero value for U describes current-revision coverage only; cryptographic integrity is checked separately.

Accepted ranges start at zero, do not overlap and remain inside the current file. The gap must exactly match the original /Contents string, including its delimiters. The revision end must coincide with an accepted PDF end-of-file boundary in the cross-reference chain, and the signature dictionary must belong within that revision. These checks prevent an arbitrary gap or unrelated revision length from being treated as valid byte binding.

Coverage arithmetic uses exact integer bytes with no percentage or rounding step. Tables and report data retain those byte counts. Large tick labels on the revision map use rounded thousands for readability; the plotted segment values remain byte counts.

Reachable signatures and original bytes

Cross-reference information identifies which PDF objects belong to the current document structure. Discovery follows the current catalog's AcroForm signature fields and its /Perms/DocMDP certification-signature reference. Repeated references to the same signature value count once. Empty signature fields do not supply a signature value.

Reading prior cross-reference sections can be necessary to resolve current objects, but this is not a search for every historical signature. Unreachable or replaced signature objects may remain among the file's bytes. Discovering a DocMDP certification signature also does not establish whether later changes comply with its modification permissions.

The digest uses the selected original bytes without rebuilding the PDF. Cross-reference tables, cross-reference streams and some object-stream structures are handled within the supported bounds, but the signature dictionary and relevant values still need an identifiable original byte location. If an original location cannot be resolved, a range is inconsistent or the structural encoding is unsupported, inspection cannot establish signed-byte integrity.

Supported signature profile and verification rules

CMS carries the signature, signed attributes and embedded certificates. Detached CMS leaves the signed document bytes outside that envelope. The supported PDF subfilters are adbe.pkcs7.detached and ETSI.CAdES.detached, with exactly one CMS signer, RSA PKCS#1 v1.5 and SHA-256. A PDF may contain several supported signature values; the one-signer requirement applies separately to each CMS value.

A successful check requires all of the following, in addition to valid original-byte binding.

  1. The CMS contains detached data and the supported digest and signature algorithms. Embedded document content, other algorithms or multiple CMS signers are outside this profile.
  2. The signer identifier matches exactly one embedded certificate by issuer and serial number or by subject-key identifier. Its public key must be RSA. The first certificate in the envelope is not automatically assumed to be the signer.
  3. Signed attributes are present and pass Distinguished Encoding Rules (DER) length and ordering checks. Exactly one single-valued content-type attribute identifies the data content, and exactly one single-valued message-digest attribute carries its digest.
  4. SHA-256 of the joined original byte ranges matches the 32-byte message digest. The RSA signature must also verify using the matched certificate's public key.

The content digest and public-key signature are both necessary. A matching digest alone does not establish a matching signature. Missing or ambiguous certificate evidence and malformed attributes are reported separately from a supported digest or signature mismatch. Accepting the ETSI subfilter does not establish full conformance with CMS Advanced Electronic Signatures (CAdES) or PDF Advanced Electronic Signatures (PAdES).

Certificate-date rules

The certificate's not-before and not-after timestamps define an inclusive interval. The date comparison uses the chosen UTC reference, independently of the signed-byte integrity result.

Certificate dates Reference instant
not yet validEarlier than the not-before timestamp.
within datesAt or after not-before and at or before not-after.
expiredLater than the not-after timestamp.
not inspectedNo signer-certificate date evidence was obtained.

The optional reference accepts a UTC date and time to the minute. A blank reference uses the instant the inspection starts. Changing it can change the date classification while the original-byte integrity remains the same. An expired date result therefore does not convert intact signed bytes into failed integrity.

Claimed signing time (unverified) comes from the CMS signing-time attribute when available. It is not a verified timestamp and is not substituted for the selected date reference. Choosing a past reference does not prove that the signature existed then or that the certificate was trusted and unrevoked at that time.

Input and resource bounds

Inspection has a bounded file and signature scope. A PDF can be valid in another application while exceeding these limits or using an unsupported structure.

Item Limit Meaning
Local PDF10 MiBOne nonempty, unencrypted file, no larger than 10,485,760 bytes.
Reachable signature values10Distinct signature values in the current discovery scope.
CMS value per signature512 KiBAt most 524,288 decoded bytes, including any padding.
Embedded certificate entries24Per CMS signature value.
Inspection deadline10 secondsConfigured time budget for loading and inspection, not a promised completion time.

Further structural bounds include 100,000 parsed PDF items, PDF nesting depth 64 and up to 128 cross-reference-chain sections. CMS binary structures use Abstract Syntax Notation One (ASN.1), with each scan bounded to 20,000 elements and nesting depth 32. Decoded structural streams are limited to four filter stages, a 4 MiB buffer and a 16 MiB aggregate decoded-buffer allocation budget. These are parsing bounds, not a total browser-memory cap.

A file-level size, structure or range failure can stop the whole inspection. A certificate-count or ASN.1 limit can instead leave a Limit reached signature row in a completed report. Neither outcome establishes integrity for the unchecked data.

Privacy and Limitations:

The selected PDF is processed locally and is not uploaded. Supporting files for verification and the byte map can be downloaded when needed, so first use is not guaranteed to work without a network connection. Native WebCrypto must be available in a supported secure browser context.

  • The PDF is not rewritten, signed or repaired. No private key is requested, no certificate is installed and no certificate, revocation or timestamp service is contacted.
  • Certificate-chain trust, revocation, timestamp-authority verification, long-term validation and legal authenticity are outside the inspection. The report is evidence for further review, not a trust attestation.
  • Cancel stops active inspection. Clear releases the selected file and results; reloading does not restore them. The optional date reference can be represented in the page URL, but PDF bytes, file names and results are not placed there.
  • Downloaded reports contain inspection metadata, not an embedded PDF or replacement signed document. They can still contain a file name and certificate identity details, so consider those details before sharing a report.

Worked Examples:

These examples use the supplied synthetic documents and do not describe a real person's signature or certificate.

An intact revision with a later update

Choose Later update appended, then Use sample. Its /ByteRange [0 511 16897 319] covers a 511-byte prefix and a 319-byte suffix. The excluded value spans 16,386 bytes, so Signed revision bytes is 17,216 even though only 830 bytes are hashed. The current file is 17,381 bytes, leaving 165 Later uncovered bytes. The result is Earlier revision intact, with Signed bytes intact in the signature row and Older revision; later bytes uncovered for coverage. The later update needs separate review; the intact earlier revision does not settle its acceptability.

A future reference with expired certificate dates

Load Intact signed example and set Date reference (UTC) to 1 January 2050 at 12:00. The sample certificate is expired at that reference, while the signature's Signed bytes intact finding remains. Signer trust is still Not evaluated. This comparison establishes the certificate's date classification at the chosen instant; it does not verify a historical signing time or create a trust decision.

References: