How Big Are PDFs, Really? A Look at Document Sizes Across Industries

The Question Nobody Actually Benchmarks

Every developer who has ever built a document upload feature has made a decision about file size limits—usually something round like 10 MB or 25 MB—without any real data to back it up. And every operations manager who has watched cloud storage bills climb has wondered why their PDF archive is ballooning faster than the number of actual documents. The honest answer is that "PDF size" is a deeply contextual number. An invoice can be 40 KB or 4 MB. A scanned contract can be 300 KB or 30 MB. The format is the same. The reasons for the difference are not.

This piece digs into the actual size ranges you should expect for different document types, what's driving the weight in each category, and where the fat genuinely sits—so you can make smarter decisions about compression, storage, and tooling.

Invoices: Tiny Footprints With Hidden Exceptions

A purely digital invoice—the kind generated programmatically by accounting software like QuickBooks, Xero, or a custom billing script—is almost embarrassingly small. Typical sizes land between 30 KB and 120 KB. These documents are almost entirely vector-based: text strings, line rules, a handful of color fills. The PDF specification handles this content extremely efficiently, and since nothing is rasterized, there's almost no pixel data to store.

The exceptions blow that range apart fast. Three things reliably inflate an invoice PDF:

Embedded logos and branding assets. A high-resolution company logo dropped in as a CMYK TIFF (common in print-focused workflows) can add 1–3 MB to a document that otherwise has zero weight. Properly optimizing that single asset to a web-resolution PNG or SVG often cuts the overall file size by 80%.
Scanned backup attachments. Some finance teams attach a scanned delivery note or purchase order as an additional page inside the invoice PDF. One 300 DPI grayscale scan of an A4 page adds roughly 200–400 KB uncompressed, and color scans at the same resolution can push past 1 MB per page.
Digital signatures and cryptographic metadata. A document with an embedded X.509 certificate and timestamp token can gain 20–80 KB of pure overhead even if the visual content is trivial. When multiple signature fields are chained (common in procurement), this overhead stacks.

For practical planning: if you're storing invoices at scale, expect the median around 80–150 KB but budget for occasional outliers at 3–5 MB. Sorting your storage analytics by file size and spot-checking the top 1% almost always reveals an avoidable source of bloat.

Ebooks: Where Fonts and Images Fight for Dominance

Ebooks distributed as PDFs live in a wildly different size band than invoices, and the spread is enormous—from about 500 KB for a lean, text-heavy title to over 150 MB for a heavily illustrated art or photography book. Understanding the drivers here is genuinely useful if you're either producing or hosting ebook content.

Text-only ebooks (think technical manuals, literary fiction, business titles) are primarily limited by two things: font embedding and the number of pages. A single embedded font subset typically costs 50–200 KB. An ebook with a custom serif body font, a display headline font, and a monospace font for code samples might embed three or four font files, adding 400–700 KB before a single page of content is considered. PDF/A compliance for archival, which many publishers require, forces full font embedding rather than subsetting, which can nearly double that overhead.

Image-heavy titles are a different story entirely. A well-illustrated children's book or a design annuals-style publication typically runs 25–80 MB. The dominant cost is almost always the resolution at which images were embedded. Publishers preparing files for offset printing often embed images at 300 DPI or higher—correct for print, but completely wasteful for screen reading. A single full-bleed spread image at 300 DPI in CMYK can exceed 8 MB. Multiply that across 60 pages and you understand why some "coffee table PDF" downloads are genuinely slow even on fast connections.

A practical benchmark that's useful for comparing across publishers: a well-optimized 300-page illustrated non-fiction ebook, prepared with screen-distribution in mind, should land under 25 MB. Files over 50 MB at that page count almost always contain either print-resolution images that were never downsampled, or large numbers of embedded multimedia assets.

Scanned Contracts: The Wild West of Document Sizes

No document category has more variance—or more unnecessary weight—than scanned legal contracts. The range in real-world archives runs from 100 KB to upward of 50 MB per document, and the drivers are almost entirely technical decisions made at the point of scanning rather than anything inherent to the content.

The single biggest variable is scan resolution. Here's what the numbers actually look like across common scanner presets:

150 DPI grayscale: Roughly 50–90 KB per A4 page. Adequate for machine reading, marginal for human legibility at fine print sizes.
200 DPI grayscale: 100–160 KB per page. The practical minimum for confidently reading 8-point type.
300 DPI grayscale: 250–400 KB per page. Industry standard for legal-quality archiving.
300 DPI color: 800 KB–1.5 MB per page. Common when scanners are left on default color settings instead of grayscale, even for black-and-white documents. This is the single most wasteful setting in any scanning workflow.
600 DPI grayscale: 900 KB–2 MB per page. Rarely necessary except for documents with very small type, fine stamps, or notary seals that need to be forensically readable.

A 40-page contract scanned at 300 DPI grayscale (appropriate) runs around 10–15 MB. The same contract scanned in color at 300 DPI because someone didn't change the default setting runs 30–50 MB. Multiply that across a law firm's archive of 200,000 documents and you're looking at tens of terabytes of storage that exists entirely because of an incorrect scanner setting.

The second major variable is whether OCR (optical character recognition) was applied and how. A scanned PDF without OCR is purely a collection of image pages. A scanned PDF with an embedded text layer is slightly larger—usually 5–15% overhead—but that's a worthwhile trade: it becomes searchable and allows accurate text extraction for downstream processing. The mistake is running OCR with a tool that also re-encodes the images; some OCR workflows accidentally decompress and re-save each page image without compression, which can triple the file size while adding a text layer.

What Drives Bloat Across All Categories

Strip away the category-specific details and a few universal patterns emerge. These are the structural causes of oversized PDFs regardless of what the document contains:

Redundant content streams. Many PDF authoring tools write revision history into the file by default. Every time a document is edited and resaved, a new content stream is appended rather than replacing the old one. Opening a five-year-old contract in Adobe Acrobat and saving it without running "Reduce File Size" can mean you're carrying six or seven complete versions of the document inside a single file.
Unconverted color spaces. RGB images placed in a document intended for screen distribution are fine; RGB images that have been through a CMYK conversion and back often carry embedded ICC profiles that add 500 KB–2 MB of color metadata per document.
Unoptimized thumbnail and preview data. macOS Preview, in particular, has a well-documented behavior of embedding a large thumbnail cache inside saved PDFs. A document edited repeatedly in Preview can accumulate several megabytes of preview data that serves no purpose in the final file.
Overly cautious DPI choices. This one appears in all three categories. Screen-distributed documents rarely benefit from anything above 150 DPI for images. Print-intended documents don't need to go above 300 DPI for most content. The reflex to "scan at maximum quality" or "export at highest resolution" without considering the use case is probably responsible for more wasted storage than any other single factor.

What "Normal" Should Actually Look Like

Building a storage system, setting upload limits, or just trying to understand why your document archive costs what it does? Here's a consolidated reference for what optimized, production-quality documents in each category should actually weigh:

Programmatic invoice (1–3 pages, optimized logo): 60–200 KB
Invoice with scanned attachments (4–6 pages): 400 KB–1.5 MB
Text-heavy ebook (200–400 pages, 3 embedded fonts): 1.5–4 MB
Illustrated non-fiction ebook (screen-optimized, 150–250 pages): 8–25 MB
Scanned contract, 300 DPI grayscale with OCR (20–40 pages): 6–15 MB
Scanned contract, 300 DPI color without OCR (same length): 25–60 MB — almost always reducible by 60–80%

The gap between "what most organizations actually have" and "what they should have" is almost always compressible without any quality loss. The tools exist. The bottleneck is usually knowing where to look—which starts with understanding that PDF file size is never arbitrary. Every extra kilobyte is there for a reason, and most of those reasons are fixable.