Signed PDF Gets Much Bigger (Size Grows After Signing)
Signing adds bytes on purpose: certificate chains, optional revocation blobs, and a signature appearance graphic. When the jump is megabytes, one of those three ran away.
A 135 KB contract becomes ~2 MB the moment the seal lands. That is not magic — signing is additive, and three bags of bytes just got stapled on.
Where the kilobytes go
| Contributor | Typical impact | Lever |
|---|---|---|
| Certificate + chain | KBs–low 100s KB | Normal; needed for trust path |
| Signature appearance image | 100s KB–MBs | Biggest common lever — keep art small |
| Embedded revocation (CRL/OCSP) | KBs–MBs+ | Fat CRLs explode when PKI misbehaves |
| Incremental save history | Accumulates | Sign once; don't re-save after seal |
| Multiple signatures | Each adds an increment | Coordinate counter-signers |
A worked example
The signature value itself is trivial — a certificate and a cryptographic digest, usually a few kilobytes. Almost all of the growth comes from two choices you can make before signing. Starting from the same 135 KB unsigned contract:
| Appearance and revocation choice | Rough size after signing | What drove it |
|---|---|---|
| Minimal vector stamp, no embedded revocation | ~150–175 KB | Just the certificate chain |
| Small raster logo (≈20 KB), online validation | ~160–190 KB | Appearance image + cert |
| Scanned wet-signature image (≈300 KB) | ~450–480 KB | The appearance image |
| High-resolution photo of the signature page | ~1–2 MB | The appearance image, again |
| Any of the above plus embedded full CRL | adds 50 KB – several MB | The revocation blob |
| A second counter-signature | one more increment each | Repeated incremental updates |
These are illustrative ranges, not guarantees — a certificate chain, a lazy signature image, and a badly behaved Certificate Authority can each move the number by more than the others combined. The point is that the contract did not change; your signing choices did.
Why revocation data can balloon
A signature can carry revocation status — proof that the signing certificate had not been revoked at signing time. Two mechanisms matter here:
- CRL (Certificate Revocation List) — the CA's full list of revoked serial numbers. Lists grow as the CA revokes more certificates, and an embedded one is stored whole. This is the usual culprit behind multi-megabyte jumps.
- OCSP (Online Certificate Status Protocol) — a small signed response for one certificate. Compact when stapled, but it makes the validator depend on network reachability.
Embedding revocation data is what lets a file validate offline; skipping it keeps the file small but assumes the reader can reach the CA. If your policy or portal does not require offline validation, disabling embedded revocation is the single biggest lever after the appearance image. ETSI's PAdES standards (EN 319 142) define how this validation material is carried inside a PDF and are the reference when a validator and a signing tool disagree.
Diagnostic order
- Compare sizes: before sign vs after (note each counter-sign).
- Inspect appearance — is it a 2 DPI-class photo of a wet signature?
- Signature panel / advanced properties — revocation embedded?
- Portal still too tight? Fix on the unsigned master, then re-sign.
You cannot fix it with compress-after
Post-sign compression changes bytes → invalid seal (why signatures break). BytePDF's rewrite tools refuse signed inputs for the same reason (operating boundary). The order is always: size pass → sign → send that exact file.
Before the portal cap bites
- Compress the unsigned draft to leave headroom
- Sign with a minimal appearance.
- Test the final bytes against the cap after signing
Honest BytesPDF scope
Sign computes a PKCS#7 signature on device (tool page = capability source). We do not promise a maximum signed size — appearance and cert chain dominate. No post-sign compress path exists by design (signed files refused for rewrite tools).
Portal workflow that fits under the cap
- Compress unsigned draft to cap − margin
(target size).
- Sign once with a minimal appearance; disable bulky revocation embed if
policy allows online validation.
- Measure again — this is the number the portal sees.
- Upload; archive the sealed file byte-for-byte
If step 3 blows the cap: re-open the unsigned compressed master (not the sealed one), simplify appearance, re-sign. Never "shrink" the sealed file.
Counter-signature etiquette
Each additional signature can append another incremental update. Collect signatures in one coordinated pass when possible; each party should receive the previous sealed bytes, not a re-exported flattened copy (verify chain).
Sources
- ETSI EN 319 142 (PAdES) — the European standard defining PDF Advanced Electronic Signatures and how validation material (including revocation data) is embedded.
- Adobe's PDF reference documentation on signature dictionaries and appearance streams.
Frequently asked questions
Why is my PDF megabytes larger after I sign it?
Signing embeds the certificate (and often a chain), a signature appearance (a high-resolution image balloons this), and optionally revocation info (CRL/OCSP responses) so validators can check offline. Incremental updates keep prior bytes too. A small appearance without embedded CRLs stays small; multi-MB jumps are usually appearance image or fat CRL data.
How many bytes does a digital signature actually add?
The signature object itself is tiny — the cryptographic value and certificate are usually a few kilobytes. The variability comes almost entirely from the signature appearance image and any embedded revocation data. A minimal vector or small raster appearance keeps growth in the tens of kilobytes; a photographed wet-signature image can add hundreds of kilobytes to a megabyte on its own.
Can I compress the PDF after it is digitally signed?
No — any rewrite that changes signed bytes invalidates the seal. Compress first, sign last. If the signed file exceeds a portal cap, the fix is a lighter appearance / no embedded revocation at sign time, or ask the portal for a higher cap — not a post-sign compress.
How do I keep signatures from inflating the file?
Use a simple vector-style or small raster appearance; avoid embedding huge scanned signatures. Disable 'include revocation status' style options when policy allows online fetch. Sign once at the end (each counter-signature can add another increment).
Does BytesPDF Sign embed revocation data?
Match the Sign tool page: PKCS#7 signature computed on device. Validation trust behavior is covered in verify + timestamps guides. Regardless of tool, the universal rule stands — do not rewrite after sealing ([why signatures break](/blog/why-is-my-pdf-signature-invalid)).
Portal rejects the signed file for size — what now?
You cannot strip bytes without breaking the seal. Options: re-sign with a minimal appearance from the unsigned master (compress the unsigned file first), use a visible stamp workflow if the portal does not require cryptographic signatures, or request an exception. Be explicit with reviewers about which file is authoritative.
Related comparisons
Source-led comparisons written by BytesPDF, with the conflict of interest disclosed on each page. They link official provider documentation rather than fabricated tests.