Why a Scanned PDF Is So Much Bigger Than It Needs to Be

A ten-page scanned form bounces off an email attachment limit. A photographed receipt bundle stalls uploading to a web form with a 5MB cap. The document itself is short - the file is just heavy. That's rarely because a PDF is an inherently bulky format; it's because every page in it is a full-resolution photograph, saved by an app that had no reason to guess how small it could safely go.

A scan is a photo pretending to be a document

Text typed directly into a document is stored as text - a handful of bytes per character, regardless of how many pages it spans. A scanned or photographed page is stored as an image - millions of individual pixels, each contributing to the file size whether the page is mostly white space or densely printed. A ten-page typed PDF and a ten-page scanned PDF can hold the same words and land two orders of magnitude apart in file size, because they're fundamentally different kinds of data wearing the same file extension.

Phone scanner apps default toward quality, not size

A scanning app's whole job is producing something legible from imperfect lighting and an unsteady hand, so most default to a high resolution and a high JPEG quality setting to leave margin for error - reasonable on its own, but it means the resulting embedded images are saved well above what's actually needed to read printed or handwritten text clearly. Nobody chose that quality level on purpose for any specific document; it's just the app's safe default, applied uniformly whether the page is a dense legal contract or a mostly-blank signature form.

Where the size actually goes wrong

It's not just resolution. A phone photo saved as a maximum-quality JPEG can be several times larger than the same image re-encoded at a quality setting a human eye can't tell apart from the original at normal viewing size - the difference between the two is redundant data, encoding detail beyond what anyone will ever look closely enough to see. Stack that redundancy across every page of a multi-page scan and it compounds into exactly the kind of file that bounces off a 25MB email limit or a 5MB upload form.

Who runs into this

Someone attaching a scanned document to an email that bounces because it's over the provider's size cap. A small business uploading a scanned invoice to a portal that rejects anything over 5MB. A student submitting a photographed assignment through a form with its own silent ceiling. Anyone who scanned something with a phone app that, reasonably, erred toward quality over size.

Why this doesn't apply to every PDF equally

A PDF that's already just typed text has nothing in it that this problem describes - there are no oversized embedded photos to shrink, because there are no embedded photos at all. Feeding a text-only PDF through a compressor that doesn't check for this can actually make the file larger, not smaller, by rebuilding the document's internal structure around content that didn't need rebuilding. A compressor worth using checks for this and returns the original file, unchanged, when there's genuinely nothing to compress - covered directly in the how-to guide.

What compressing an image inside a PDF doesn't touch

It's worth separating "smaller file" from "smaller page." Re-encoding an embedded image at a lower quality changes how many bytes it takes to store that image - it doesn't change the page's dimensions, the layout, the text, or how large the image appears when the PDF is opened and read. A compressed scan still looks like the same document at the same size on screen; what's different is invisible at normal viewing size and only shows up in the file's weight, not its appearance.

Where this fits

Compress PDF finds the embedded photos in a scanned or photographed PDF and re-encodes them smaller, entirely inside the browser - no upload of the scanned form, receipt, or contract this whole problem is about. The how-to guide covers the actual steps, and this guide covers choosing a preset when there's a specific size limit to hit.