Your PDF compressor might be destroying the text layer

If your compressed PDF has lost its text layer, the compression ratio isn't the problem. The method is.

I compressed a 7.28 MB scanned report down to 560 KB last week. Then I hit Ctrl+F and found nothing. Not a single word. My first instinct was to dial the compression back — didn't help. The text was already gone.

Two very different things are called "PDF compression"

Full-page rasterization. Render each page to a bitmap, pack the bitmaps into a new PDF. Simple to implement, great numbers. It destroys the text layer, vector graphics, links and bookmarks. You end up with a photo album, not a document.

Structural re-encoding. Parse the PDF object tree, find the embedded raster images, re-encode them one by one. Text, vectors, fonts, links stay untouched.

Both can hit similar size reductions. Only one leaves you with a working document.

Where the bytes actually are

Text and vector graphics are tiny. Fonts run tens to a few hundred KB. What pushes a PDF into the megabytes is almost always embedded bitmaps — scans, photos, screenshots.

So structural re-encoding only has to touch the images. It gets nearly the same savings without wrecking anything else.

What "structural optimization" actually does

This part is easy to overlook because it never shows up as a dramatic number.

A PDF accumulates junk. Objects that nothing references anymore. Duplicate resources. Content streams that were never compressed, or compressed with something worse than Flate. Fonts listed in a page's resource dictionary that the page doesn't actually draw with.

A structural pass walks the real drawing operators, works out what is genuinely reachable, and drops the rest. It recompresses streams, merges fragmented content streams where it is lexically safe to do so, and repacks objects.

None of that touches a single pixel. It is lossless by construction. On my test file it accounted for 4 reclaimed resources and 4 recompressed streams — worth maybe a percent on its own, but it applies even when you refuse to downsample anything.

Deciding whether an image should shrink at all

Not every embedded image needs downsampling. The deciding factor is effective DPI: pixel count divided by the physical size the image actually occupies on the page.

A 2400px-wide image filling an A4 page and the same image tucked into a corner need completely different resolutions.

Running a 4-page report through, the tool reported an effective DPI of 359×452.

Two numbers. Horizontal 359, vertical 452. Images can be placed with non-uniform scaling, so the two axes genuinely differ. Judge by one axis only and you either over-shrink or leave dead pixels behind.

Four presets, measured

Same file, four presets:

Preset	Output	Reduction	Images re-encoded	Downsampled to
Screen / email 72 dpi	98 KB	−98.7%	4/4	481×255 · q82
E-book 150 dpi	560 KB	−92.5%	4/4	1003×531 · q88
Print 300 dpi	3.08 MB	−57.7%	4/4	2400×1062 · q92
Lossless structural	7.27 MB	−0.1%	0/4	untouched

That last row is the interesting one. Zero images re-encoded, size barely moved — yet it still reclaimed 4 unused resources and recompressed 4 structure streams.

Structural optimization and image downsampling are two independent things. The first is always lossless.

Proving nothing broke

Size reduction alone means nothing. I read all three outputs back with a PDF parser:

	Original	72 dpi	150 dpi	300 dpi
Pages	4	4 ✓	4 ✓	4 ✓
Extractable text	2723 chars	2723 ✓	2723 ✓	2723 ✓
Link annotations	4	4 ✓	4 ✓	4 ✓
MediaBox	595.3×841.9	same ✓	same ✓	same ✓

The preset that cut the file to 1.3% of its original size lost exactly zero characters.

The tool runs its own check as the last pipeline step — parse structure → re-encode images → reclaim objects and write → read back and verify pages. Same thing I did externally.

When rasterization is actually the right call

I have been dismissive of full-page rasterization, so to be fair — it has legitimate uses:

• You want to prevent text selection. Sending a contract sample or an internal document outward, where copy-paste is exactly what you're trying to stop.
• The source structure is already broken. Some PDFs are malformed enough that no parser can walk them safely. Rendering is the fallback that always works.
• Font licensing blocks embedding. If you can't legally carry the fonts into the target environment, outlines or pixels may be your only option.

Outside those cases, for everyday "this file is too big to email" problems, it's the wrong tool.

Where it stops working

Text-only PDFs barely compress. A 6-page text document went from 37 KB to 33 KB — 11%. Zero embedded images means nothing to re-encode. Contracts and papers won't benefit.

Encrypted PDFs need their protection removed first.

Digitally signed PDFs lose their signature on any rewrite. That's structural, not tool-specific.

Some image formats stay as-is: JPEG 2000, JBIG2, CCITT fax, CMYK print JPEGs. A browser can't reliably re-encode those to an equivalent, so they're preserved untouched.

A three-second check before you send anything

Forget the advertised compression ratio. Do this instead:

1. Search for a word in the document
2. Click a link
3. Check the page count

All three intact means it was compressed. Any one missing means it was downgraded.

There's a fourth check worth doing if the file matters: zoom to 400%. Text that stays crisp is still text. Text that turns fuzzy has already become pixels — the file will look fine at 100% and fall apart when someone actually reads it on a large display.

If you want the same verification programmatically, any PDF library that exposes page count, extracted text and link annotations will do. That's exactly the check I ran above, and it takes about ten lines.

---

Disclosure: I work on ImgIng (imging.ai), the tool used for these measurements — its PDF compression runs entirely in the browser, nothing uploaded. Every number above was measured while writing this post; the method is described so you can reproduce it.