Why PDF Files Expand in Size When Merging or Converting: Deep Technical Analysis

One of the most frustrating experiences in digital document management is merging two 1 MB PDF files only to produce a 15 MB output document. Or converting a single-page Word file containing a couple of paragraphs into a PDF and watching the file size balloon by 1000%.

To most users, this size expansion feels completely random. However, PDF file size bloat is governed by precise mathematical and architectural factors within the PDF (ISO 32000) binary specification.

In this 2,100+ word technical deep dive, we analyze the root causes of PDF file size expansion during merge, conversion, and editing workflows. We deconstruct font subset duplication, uncompressed stream dictionaries, color space transformations, vector rasterization traps, and incremental revision logs—and demonstrate how to compact PDFs 100% in your web browser using WebAssembly stream optimization.

1. The Core Architecture of PDF File Size

To understand why PDFs expand, we must examine how data is structured inside a PDF document.

A PDF is not a continuous stream of formatted text like an HTML document. Instead, a PDF is an object-oriented database consisting of independent objects linked via a Cross-Reference Table (xref).

┌──────────────────────────────────────────────────────────────┐
│ PDF File Binary Structure                                    │
├──────────────────────────────────────────────────────────────┤
│ 1. Header  (%PDF-1.7)                                        │
├──────────────────────────────────────────────────────────────┤
│ 2. Document Catalog & Page Tree                              │
├──────────────────────────────────────────────────────────────┤
│ 3. Content Streams (Vector commands, text positioning)       │
├──────────────────────────────────────────────────────────────┤
│ 4. Resource Dictionaries (Embedded Fonts, Images, Color)     │
├──────────────────────────────────────────────────────────────┤
│ 5. Cross-Reference Table (xref)                              │
├──────────────────────────────────────────────────────────────┤
│ 6. Trailer                                                   │
└──────────────────────────────────────────────────────────────┘

When a document expands, the size increase rarely comes from the text content itself. Text operations represent only a tiny fraction of the total byte count. Rather, size expansion stems from Resource Dictionaries—specifically embedded font programs, unoptimized image streams, and redundant metadata trees.

2. Factor 1: Duplicate Font Embedding & Subsetting Overhead

Typography is the single most common cause of unexpected PDF file expansion during merge operations.

Understanding Font Subsetting

When a document is converted to PDF, the application embeds font files (such as TrueType .ttf or OpenType .otf files) into the document so that the PDF renders identically on any computer, regardless of installed system fonts.

To save space, PDF engines perform Font Subsetting:

• Full TrueType Font (Inter Regular): Contains over 1,200 character glyphs ($\approx 450 \text{ KB}$).
• Subset Font: Embedded font containing only the 35 distinct character glyphs actually present in the document ($\approx 25 \text{ KB}$).

Full Font File (450 KB)  ──>  Font Subsetting Engine  ──>  Subset Font Dictionary (25 KB)

The Merge Duplication Problem

When you merge ten separate PDF files created by different applications or users:

1. Document 1 contains a subset of Inter Regular (Object ID 12 0 R).
2. Document 2 contains another subset of Inter Regular (Object ID 24 0 R).
3. Document 3 contains another subset of Inter Regular (Object ID 36 0 R).

Naive PDF merging tools simply concatenate the object trees from each source file without inspecting internal font tables. As a result, the output merged PDF contains ten separate embedded font dictionaries for the exact same font family!

Unoptimized Merge Pipeline (File Inflation):
[Page 1 + Inter Subset 1] + [Page 2 + Inter Subset 2] + [Page 3 + Inter Subset 3]
  │
  └── Output: 3x Font Objects embedded (75 KB font overhead for 3 pages!)

Optimized WebAssembly Merge Pipeline (Compact):
[Page 1 + Inter Subset 1] + [Page 2 + Inter Subset 2] + [Page 3 + Inter Subset 3]
  │
  ├── 1. Parse CFF / CMap Glyph Tables
  ├── 2. Unify character glyph maps into single Font Dictionary
  └── Output: 1x Unified Font Object (28 KB total font overhead!)

When documents utilize multiple custom corporate typefaces across dozens of merged pages, duplicate font subsetting alone can add 5 MB to 20 MB of redundant binary data.

3. Factor 2: Image Stream Compression & Color Space Conversion

Images embedded inside PDFs account for the majority of raw byte weight. During file conversion or editing, image streams frequently undergo accidental un-compression or color space expansion.

A. Color Space Expansion: RGB vs. CMYK

Digital displays display images using 3-channel RGB (Red, Green, Blue) color space. Commercial printing presses require 4-channel CMYK (Cyan, Magenta, Yellow, Key/Black) color space.

$$ \text{RGB Raw Byte Memory} = \text{Width} \times \text{Height} \times 3 \text{ bytes} $$

$$ \text{CMYK Raw Byte Memory} = \text{Width} \times \text{Height} \times 4 \text{ bytes} $$

When a document generator converts an RGB image into CMYK during PDF creation:

• Every pixel instantly requires 33% more raw byte data.
• High-resolution ICC Color Profiles (often adding 500 KB to 2 MB of profile data) are attached to every individual image object stream.

RGB Image (3 Channels) ──[Conversion to CMYK]──> CMYK Image (4 Channels) + ICC Profile (+33% Data Size!)

B. Loss of Lossy Compression (FlateDecode Fallback)

JPEG images use lossy Discrete Cosine Transform (DCT) compression natively wrapped in DCTDecode streams inside PDFs.

However, when an unoptimized PDF converter processes a JPEG image (for example, applying a slight rotation or cropping mask):

1. The engine decompresses the original JPEG back into raw uncompressed pixels.
2. Instead of re-encoding the image with JPEG compression (DCTDecode), the engine compresses the raw pixels using lossless FlateDecode (zlib).

Lossless FlateDecode is designed for text and vector data—it performs terribly on photographic pixel arrays. A $500 \text{ KB}$ JPEG photo re-encoded with FlateDecode can easily balloon to $5 \text{ MB} - 8 \text{ MB}$ inside the PDF stream!

4. Factor 3: Incremental Update Logs & Orphaned Objects

PDF is an incremental file format by design. This allows desktop applications to save changes quickly without rewriting multi-gigabyte documents from scratch.

How Incremental Saves Work

When you open a 2 MB PDF in an editor, delete 5 pages, and click “Save”:

[Original PDF Content: Pages 1, 2, 3, 4, 5] (2.0 MB)
  │
  └── [Incremental Update appended to end of file]
      ├── Modified Catalog (pointing to Pages 1, 2 only)
      ├── New xref Table
      └── New Trailer (%%EOF)

Notice what happened: The deleted pages (Pages 3, 4, and 5) and their high-res images were NOT removed from the disk file!

The application simply appended a new cross-reference table to the end of the document that excludes references to those pages. The old, deleted objects remain embedded inside the file as Orphaned Objects.

If a document undergoes dozens of editing sessions, the file size continuously grows even as text and pages are deleted.

5. Factor 4: Vector Transparency & DPI Rasterization Traps

Modern graphic design software relies heavily on vector transparency masks, drop shadows, blend modes, and gradient meshes.

The Vector-to-Raster Fallback

PDF viewers prior to PDF 1.4 (or legacy print drivers) cannot render vector transparency natively. When exporting a document containing complex overlapping vector layers to a legacy PDF format:

Vector Layers with Transparency (Drop Shadows, Gradients)
  │
  └── Legacy Flattening Engine
      │
      ├── Converted to High-DPI Bitmap (Rasterization)
      └── Embedded as 600 DPI Uncompressed Image Stream!

Instead of keeping lightweight mathematical vector lines (a few kilobytes), the export engine converts the entire page area into a huge, high-DPI raster image (20+ MB).

6. How to Diagnose & Fix PDF File Inflation

Technical Diagnostic Checklist

If a PDF file size inflates unexpectedly, check the following structural parameters:

7. How HateMyPDF Compacts PDFs 100% Client-Side

Traditional online PDF compressors require uploading your confidential legal documents, bank statements, and tax forms to third-party cloud servers. This exposes sensitive data to network security risks and privacy violations.

At HateMyPDF, we engineered a 100% Client-Side PDF Optimization Engine using WebAssembly:

[Your Browser Local RAM]
  │
  ├── 1. PDF loaded into Web Worker memory tab
  ├── 2. QPDF / Poppler WASM engine parses object tree
  ├── 3. Garbage Collects Orphaned Objects & Incremental Logs
  ├── 4. Deduplicates Font Subsets & Re-encodes JPEG Streams
  └── 5. Generates compact PDF Blob directly to disk (Zero Uploads!)

What Our Client-Side Engine Does Automatically:

1. Garbage Collection: Scans the document object graph, identifying and purging all orphaned objects and legacy revision logs.
2. Font Deduplication: Merges duplicate font subsets across merged documents into unified character maps.
3. Stream Re-compression: Re-encodes image streams using optimized lossy DCTDecode compression while keeping vector text sharp.
4. Clean Cross-Reference Rebuilding: Generates a fresh, compact xref table from byte offset 0.

8. Experience Private In-Browser PDF Processing

Try our free client-side PDF tools right now with 100% privacy guaranteed:

• Compress PDF - Shrink PDF file size locally in your browser.
• Merge PDF - Combine PDFs with automatic font subset deduplication.
• Split PDF - Extract pages instantly without cloud uploads.
• PDF to Images - Convert PDF pages to high-resolution PNG/JPG.
• PDF to Word - Transform PDF documents into editable Word format.