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 |
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).
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.
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.