PDF Signature Verifier
Checks a PDF's PAdES/ICP-Brasil signature — who signed, when, and whether the chain is trustworthy.
The selected file is read and verified entirely on your device — extracting the signature, checking it cryptographically, and validating the certificate chain all happen locally, with no byte of the document ever sent to any server, not even Nexinon's. This holds even for the most sensitive official documents (contracts, powers of attorney, declarations) — the official government validator, by comparison, requires uploading the file to verify it.
What PAdES is
PAdES (PDF Advanced Electronic Signatures) is the standard defining how a digital signature lives inside a PDF file, without needing a separate file. The signature (a CMS/PKCS#7 cryptographic structure) sits embedded in the PDF itself, together with a field called /ByteRange, which states exactly which bytes of the file were signed. That field is what makes it possible to detect whether anything changed in the document after signing.
How /ByteRange works
Every signed PDF has a /ByteRange field with four numbers — they say "the bytes from this position to that position, and then from that position to this other one, were signed", skipping only the stretch where the signature itself is written (the /Contents field). This tool reconstructs exactly those bytes and checks whether their hash matches what the signature attests — the same math any serious PAdES validator uses, done here entirely in your browser.
What a "shadow attack" is
PDF has a legitimate feature called incremental update — it lets you add new content (like a second signature) without touching the already-signed bytes, preserving the previous signature's validity. A "shadow attack" abuses that same mechanism: someone appends content after the last valid signature — text, images, even form fields that change what's shown on screen — with no signature covering that new stretch. A regular PDF reader opens it and shows the added content, and a validator that only checks "does the signature match?" still says yes, because technically it does — it just no longer covers the whole document. This tool detects that scenario by comparing where the most recent signature's coverage ends against the file's actual size.
ICP-Brasil signature policy levels
ICP-Brasil defines four main advanced signature formats — AD-RB, AD-RT, AD-RC, and AD-RA — each adding a layer of guarantee over the previous one, from the simplest (just the signature) to the most complete (validation data attached, meant to last decades). The format is identified by a technical OID inside the signature itself, decoded automatically by this tool.
Classic ICP-Brasil vs. the gov.br Signer
Two trust hierarchies are recognized today by the Brazilian government for signing a PDF: classic ICP-Brasil (a paid e-CPF/e-CNPJ certificate, bought from an accredited certificate authority) and the gov.br Signer (free, tied to your gov.br account at silver or gold verification level, backed by Law 14,063/2020 — "advanced electronic signature"). Both use the same underlying PAdES technical standard, but different certificate chains. This tool recognizes both.
Why the timestamp matters
The date shown as "signed on" can come from two sources with very different reliability: the signer's own computer clock (easy to set forward or back) or an RFC 3161 timestamp, issued by a trusted third-party authority at the moment of signing. A timestamp proves the signature already existed at that instant, independent of anyone's clock — important above all to prove the signature was made while the signer's certificate was still valid.
What this tool doesn't check: revocation
A digital certificate can be revoked before its normal validity period ends (a lost token, a compromised key, etc.) — confirming that requires querying a revocation list (CRL) or an OCSP server over the internet. Since this tool's core commitment is to never make a single network call, that specific check is left out: verification here confirms the signature is mathematically valid and that the chain is structurally trustworthy, but it does not confirm whether the certificate was revoked after issuance. For that extra guarantee, use the official government validator (validar.iti.gov.br), which does make that network query.
Frequently asked questions
No — it only verifies a signature that already exists. Signing requires a private key (your own digital certificate), a quite different and more sensitive operation than checking someone else's signature. Nexinon deliberately separates the two.
Confirming revocation requires querying a server (a revocation list or OCSP) over the internet — which contradicts this tool's 100%-local guarantee specifically for that check. It's a deliberate scope boundary, stated clearly, never a hidden limitation.
It means the signature is mathematically valid (the document wasn't altered), but the certificate used wasn't issued by any recognized certificate authority — it could be a self-signed certificate anyone could create in minutes. This is the central scenario of a forged document: the signature "works" technically, but doesn't prove anyone's identity.
Yes, that's the explicit goal: beyond a valid/invalid verdict, this tool shows the certificate chain link by link, detects content altered after signing (shadow attack), decodes the ICP-Brasil signature policy, details the timestamp, and does all of that without the file ever leaving your browser — the official validator requires uploading the PDF to the government's server.
A multi-party contract can have a signature field for each signer. Each signature is an independent structure, with its own certificate and its own /ByteRange (covering the document up to the point that person signed) — so each one is verified and shown separately, in the order they were made.
No. No byte of the PDF leaves your browser — there's no upload, no server-side storage. The entire verification (extracting the signature, checking it cryptographically, validating the chain) happens locally, on your own device.
It's the technical identifier of exactly which variant of the signature standard was used — the most common are adbe.pkcs7.detached (older format, still common), ETSI.CAdES.detached (today's European/ICP-Brasil standard), and ETSI.RFC3161 (a signature that is itself just a timestamp). It doesn't change what the signature guarantees in practice — it's a forensic-level detail, which is why it lives in a separate technical section.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.