How to Make a PDF Smaller Without Losing Quality
Practical ways to shrink PDF file size while keeping text sharp and images clear: image compression, downsampling, grayscale, and when each one is worth it.
NewKitApp 10 min read
You finish a report, attach it to an email, and the mail app refuses to send. The PDF is 38 MB and the limit is 25. You click "compress" in some free online tool, upload the file, and get back 4 MB of blurred screenshots. The text looks like a fax from 1995.
It does not have to work that way. A PDF can shrink to a fraction of its size with the text staying exactly as sharp as before, because text in a PDF is not made of pixels. This guide explains what actually takes up space in a PDF, which levers reduce it, and how to pick settings that match what the file is for.
What is inside a big PDF
A PDF is a container. Inside you find some combination of these objects:
Text as vectors. Every letter is stored as drawing instructions plus a reference to a font. This is why zooming a text PDF to 800 percent still shows clean edges. Vector text takes almost no space. A 400-page novel that is pure text often weighs under 2 MB.
Images as pixels. Photos, screenshots, scanned pages, charts exported as pictures. Each image stores a grid of colored dots, and the grid is usually far finer than any screen or printer needs. Images are the reason real-world PDFs get heavy. One scanned page at 600 dpi holds about 100 megabytes of raw pixel data before compression.
Fonts. Embedded fonts keep the document looking the same on every machine. A full font family with all glyphs for several scripts can add several megabytes. Most producers embed subsets that only contain the letters actually used, which keeps this small, but you will meet PDFs that embed everything.
Duplicates and leftovers. Some exporters write the same logo image on every page instead of storing it once. Some keep unused resources, old object versions, and metadata from earlier edits. Cleaning these costs nothing in visible quality.
Interactive parts. Forms, comments, embedded attachments, digital signatures. Usually small, but attachments can carry entire source files.
When you set out to make a PDF smaller, you are really deciding what to do with its images, and how hard to squeeze them. Text needs nothing.
What compression actually does
Two different mechanisms carry the name "compression" in PDF tools, and knowing the split helps you predict the result.
Re-encoding images. The tool takes each image inside the PDF, decodes it, and saves it again as JPEG or JPEG 2000 at a chosen quality level. JPEG throws away detail that human eyes notice least. At quality 80 the loss is close to invisible for photos. At 50 you start seeing blocky artifacts around sharp edges. Screenshots and text rendered as an image suffer first, because they consist of exactly the sharp edges JPEG finds expensive.
Downsampling images. The tool lowers the pixel grid itself. A photo placed at 10 centimeters wide does not need 3000 pixels across unless someone plans to print it billboard size. Downsampling to, say, 150 pixels per centimeter of final size keeps every pixel that a screen can display and throws the rest away. Downsampling is pure win beyond the display density, which is why it comes before quality reduction in any sane pipeline.
Lossless recompression of the rest. Streams that are not images, including text drawing commands, get Flate (the same algorithm as ZIP) recompression. Nothing is lost. This alone rarely saves much, because most producers already Flate everything.
Object cleanup. Removing duplicate images, unreferenced objects and stale revisions. Again, invisible to the reader.
Good tools apply all four in order and let you steer the image parts. That is exactly what the PDF compressor on this site does: it runs in your browser, shows you a live estimate of the result at each quality level, and never uploads the file anywhere.
A workflow that keeps quality
Open the file in the compressor and work through the levels from gentle to strong, checking the preview at each step.
Start at high quality. On a typical business report, images re-encoded at high quality plus downsampling to 150 dpi for screen use often halves the file. The preview shows you the exact number. Inspect a page that contains a photo and a page that contains a screenshot. If both look unchanged, this level is your answer.
Drop one level and compare. The next step usually halves the size again. Look at the screenshot page specifically. Screenshots with thin lines and small text are the first casualties. If the small print in the screenshot still reads cleanly at 100 percent zoom, keep going. If it smears, step back up.
Check text once, at 300 percent zoom. Zoom into ordinary body text. It must look identical at every compression level, because the tool never touches vector text. If body text ever changes, something else went wrong, such as the text actually being a scan.
Match the level to the destination. A file you will email once can stay at high quality. A file that thousands of people will download from your site deserves the strongest level that survives inspection, because you are multiplying the savings.
Stop when the purpose is met. Getting a 38 MB file under 25 MB for email does not require maximum compression. Overshooting costs quality for no practical gain.
Scanned documents are a different problem
A scan is one big image per page, so every rule about images applies with force, and the biggest lever is resolution rather than JPEG quality.
Scanners often default to 300 or 600 dpi. For a document that will be read on a screen and printed at original size, 150 to 200 dpi is plenty. Downsampling a 600 dpi scan to 200 dpi cuts pixel count by roughly 90 percent, and the text still looks crisp, because 200 dpi is beyond what a normal printer resolves on plain paper anyway.
If the scan contains handwriting or fine serif print, stay above 150 dpi. If you plan to run OCR later, keep at least 200 dpi, because OCR engines read lower resolutions measurably worse.
Grayscale helps scans too. A color scan of a black and white page spends three channels of data on what is essentially one. Converting to grayscale removes color information your document never had. The grayscale converter does this for whole files at once.
Extra levers when images are not the problem
Strip images entirely. Contracts, invoices, and text extracts do not need the letterhead photo repeated on 60 pages. The remove images tool deletes all images or only the ones past a size threshold while leaving the text layout intact. For a document whose only images are decoration, this is the largest single reduction available, far past anything recompression can reach.
Resize large pages. Posters and CAD drawings are drawn on huge pages. If the consumer only needs a reasonable preview, the resize tool scales pages down, and every embedded image placed relative to the page shrinks with it.
Split the file. When only chapter 3 of a 200-page manual is needed by the recipient, sending chapter 3 beats compressing all of it. The split tool cuts by page ranges or fixed chunks.
Flatten form fields and annotations. Interactive form layers and long comment threads add weight and also cause rendering quirks in old viewers. Flattening bakes their appearance into the page. The flatten tool handles this.
What to check before you trust the result
Compression bugs are rare but real, and two minutes of checking beats sending a broken file to a client.
Open the output and flip through every page, not just the first three. Export bugs cluster on pages with unusual content: rotated scans, transparent overlays, unusual color spaces.
Zoom to 300 percent on text and confirm the edges. Compare an image-heavy page side by side with the original if the file matters.
Check the page count stayed the same. Cheap tools sometimes drop pages after a corrupt object; the page count is the fastest integrity check there is.
For forms, click a field and confirm it still accepts input, unless you flattened on purpose.
Targets worth aiming for
Numbers help calibrate expectations. These hold for typical content, not guarantees, because a file is its contents.
Text document, 50 pages, embedded subset fonts: 0.5 to 2 MB before compression. Compression changes little, because there is nothing heavy inside. If someone sent you a 30 MB text PDF, the size sits in embedded full fonts or attached files, and the fix is re-exporting from the source, not compressing.
Report with photos, 30 pages: often 10 to 40 MB from word processors at default settings, compressing to 1 to 4 MB at high quality with 150 dpi downsampling. This is the case where people see 90 percent reductions.
Scanned manual, 200 pages at 600 dpi color: easily 500 MB. Downsampling to 200 dpi grayscale lands near 15 to 30 MB, and to 150 dpi nearer 10. If you need it under 5 MB for an email, split it.
Screencast-style documentation with screenshots: moderate reductions from recompression alone, because screenshots resist JPEG. Downsampling in small steps and removing decorative graphics does more.
Why the text never blurs
The claim that compression leaves text untouched sounds like marketing until you look at how a PDF draws a letter. The file does not contain a picture of the word "invoice". It contains an instruction roughly equivalent to: select font X at size 11, move to position (72, 144), draw the glyph sequence for "invoice". A viewer program turns those instructions into shapes at whatever size your screen shows.
Nothing in that pipeline involves pixels at fixed resolution, so nothing in it can become blurry. Compressing the file means recompressing the streams that store these instructions. The instructions come out byte for byte identical. Zoom in tomorrow at 1600 percent and the glyph outlines are as crisp as the day the file was exported.
This is also why the sharpness test for a compressed PDF is so simple. If the body text looks soft after compression, the text was never vector text in the first place. Somebody scanned a document or printed it to an image-based PDF, and the whole page is one photo. You verify this in one second by selecting a word with the mouse: real text selects, images do not.
Knowing the split changes which tool you reach for. Vector text plus heavy images is a compression job. Image-only pages are a resolution and grayscale job, sometimes an OCR job if you want the text back.
Files that refuse to shrink
Some PDFs barely move no matter what you do, and the size always has a specific reason.
The producer embedded complete fonts. Design tools sometimes embed entire typefaces with thousands of glyphs when the document uses two paragraphs of them. Compression tools keep fonts untouched by design, because re-subsetting a font can break text extraction. The fix is exporting again from the source with font subsetting enabled.
The file carries attachments. A PDF can contain other files inside it, and a 40 MB spreadsheet rides along invisibly. Check the attachments panel in a desktop viewer. Removing the attachment, where the file allows it, removes the weight at once.
Every page carries a full-resolution background photo. Some presentation tools export slides this way. Compression helps, and removing the background through the image tools helps more, but the honest fix is re-exporting the slides with sensibly sized images.
The document contains huge vector drawings. Rare, and the one case where the vector content itself is the payload. GIS plots and CAD sheets can hold millions of path segments. Downsampling does nothing to paths. Splitting the sheet into tiles is the practical answer.
Mistakes that cost quality for nothing
Recompressing a file that is already compressed. Each JPEG round trip degrades. Start from the original whenever you still have it, and keep the original archived.
Zipping the PDF before sending. PDFs with compressed content inside barely respond to ZIP, and many mail systems reject ZIP attachments on principle. Compress the PDF itself instead.
Printing to PDF as a compression method. On Windows and macOS, "print to PDF" rasterizes some content, turning sharp text into images, and produces a file that is often larger. Use a real compressor.
Trusting automatic "best for web" buttons without a preview. Different files need different settings, and the only way to know where the cliff sits is to look at a page of your own document at each level.
The two-minute version
Open the compressor, pick the highest quality level with 150 dpi downsampling, look at the preview number, and zoom the preview on one photo and one screenshot. Step down one level at a time until either the file is small enough or the screenshot starts to smear, then stop one step above that. Text never changes, grayscale scans belong at 150 to 200 dpi, decoration belongs in the trash, and 90 percent reductions are normal for photo-heavy reports that came straight out of a word processor.
The file you send tomorrow does not need to carry every pixel the scanner ever captured. It needs to look right on the screen it lands on, and you now know exactly which parts of the document decide that.