How I Turned a 200MB Client PDF Into 4MB Before a Deadline

It was 11:47 PM on a Thursday when my client sent the message I'd been dreading: "Can you send over the final brand book before our board meeting at 8 AM?"

Simple enough request. Except the PDF sitting on my desktop was 204MB. I'd spent three weeks building it — 87 pages, full-bleed photography, vector logos, embedded color profiles. It was gorgeous. It was also completely unsendable. Gmail would laugh in my face. WeTransfer would work, technically, but my client's IT department blocked large download links. Their email server had a 10MB attachment cap. I knew this because I'd already bounced off it twice that month.

I had roughly seven hours to fix a problem I didn't fully understand yet.

First Move: Figure Out What's Actually Heavy

My instinct was to just throw the file at a compressor and hope for the best. But I've done that before and gotten back a 180MB PDF instead of a 4MB one, feeling equally stuck but now with worse image quality. So I forced myself to slow down for ten minutes.

I opened the file in Acrobat and went to File → Properties → Description. Total pages: 87. Then I used the preflight tool to get a breakdown. Sure enough: images were eating 196MB of that 204. The actual text, vectors, and structure of the document? Under 8MB. So this was purely an image problem.

The images had come from three sources: a photographer who'd sent raw exports at 300DPI in CMYK (correct for print, brutal for screen), my own screenshots at native Retina resolution (4x more pixels than necessary), and a few logo files the client sent as massive PNGs with transparent backgrounds that Acrobat had apparently embedded as uncompressed bitmaps.

Once I knew the enemy, I had a plan.

The Split-First Approach That Saved Me

Here's something most people don't think about when compressing a large PDF: you don't have to compress the whole thing at once. And sometimes you shouldn't.

The brand book had distinct sections — Brand Story (pages 1–12, mostly text), Photography Guidelines (pages 13–34, all heavy images), Color & Typography (pages 35–58, mixed), and Application Examples (pages 59–87, medium density). I decided to split it first, compress each section differently based on what was in it, then merge everything back.

I used Acrobat's Organize Pages tool to extract each section as a separate file. This took about four minutes. Now I had four PDFs: 18MB, 142MB, 28MB, and 16MB.

The Photography section was clearly the culprit. I needed to be aggressive there while being gentler on the text-heavy sections to preserve readability.

Compression Settings Actually Matter

For the Photography section, I went into Acrobat's PDF Optimizer (File → Save As Other → Optimized PDF). This is the tool most people ignore because it looks complicated. It's not, once you know which knobs to turn.

Under "Images," I set color images to downsample at 150 DPI (down from 300) using Bicubic downsampling, and applied JPEG compression at quality 45. I know 45 sounds low, but for full-bleed photography in a brand book viewed on screen, the difference between quality 45 and quality 80 is essentially invisible unless you're zoomed in to 400%. I've tested this. Clients have never noticed.

For grayscale images, same settings. For monochrome (mostly logos that got embedded as bitmaps), I downsampled to 1200 DPI and used CCITT Group 4 compression, which is lossless and extremely efficient for black-and-white content.

I also ticked "Discard Objects → Discard document tags" (we didn't need accessibility structure in this deliverable), "Discard User Data → Discard all comments," and "Clean Up → Remove invalid bookmarks." These feel minor but they add up.

Photography section after optimization: 9.2MB. Down from 142MB. I actually said "okay" out loud to my empty apartment.

The Text Sections Were Trickier Than Expected

Running the same settings on the Brand Story section gave me 11MB from 18MB — respectable, but not great. The problem was that the designer (me, past me, the exhausted version) had embedded full font families instead of subsets. The Maison Neue family alone was adding nearly 6MB because I'd embedded all 12 weights even though I'd only used four of them.

In PDF Optimizer, under "Fonts," I enabled "Subset embedded fonts when percent of characters used is less than 100%." Then I re-ran the optimization. The section dropped to 4.1MB.

This is one of those settings that should honestly be on by default. If you've embedded a 900KB font file to use 40 characters from it, you should only be embedding those 40 characters. Font subsetting does exactly that.

The Merge, and the Last 20%

By 2:15 AM I had four compressed sections totaling about 22MB. I merged them back using Acrobat's Combine Files tool, making sure to maintain page order. The merged file came out at 23.4MB — the merge process itself adds a small overhead.

Still too big. The client's 10MB limit was real. So I made a judgment call: I'd deliver two files instead of one, split at the natural section break between page 34 and page 35. Part 1 (Brand Story + Photography Guidelines) and Part 2 (Color & Typography + Application Examples). I ran one final optimization pass on each.

Part 1: 6.8MB. Part 2: 3.9MB. Both under 10MB. Done.

Except — and this is the part I almost forgot — I needed to check that the compression hadn't wrecked anything visually. I exported every fifth page as a JPEG at 72DPI and spot-checked them. Pages 5, 10, 15, 20... everything looked clean. The photos had lost some micro-detail but nothing that would be visible on a monitor or in a standard office print. The typography was crisp. The logos were intact.

I sent both files at 3:08 AM with a note explaining the split and why. The client replied at 7:52 AM: "These look great, thank you." Board meeting went fine.

What I Do Differently Now

That night rearranged how I think about PDF delivery. A few things I now build into my workflow from the start:

I set a target file size before I start building. Screen-only delivery? 5MB max. Print delivery to a print shop? Size doesn't matter, quality does. Client email? Under 8MB always. Knowing this before I start means I'm making smarter choices about image resolution during design, not surgery afterward.

I use split-compress-merge for any document over 50 pages. It gives you granular control and makes troubleshooting easier. If the re-merge is larger than expected, you know which section to revisit.

I compress in Acrobat's optimizer, not "Save As PDF" from Illustrator or InDesign. Those applications optimize for fidelity, not file size. Acrobat's optimizer is purpose-built for reduction and gives you actual control over what gets changed.

For anything over 25MB after compression, I split by natural section. Two 8MB files are infinitely more usable than one 23MB file that nobody can open in their email client. People appreciate the thought, and it actually communicates that you understand how they're going to use the document.

The Tool Situation

I use Acrobat Pro for this because I have it, but I want to be honest: you don't need it for most of these tasks. Smallpdf's split and compress tools handle the basics well. ILovePDF has a decent batch compressor. Sejda lets you set custom DPI targets, which is the feature most of the free tools are missing. If you're doing this occasionally, the free tiers of those services are usually enough.

Where Acrobat earns its keep is in the optimizer's granularity — being able to handle color, grayscale, and monochrome images with different settings in a single pass, and the font subsetting, is hard to replicate in browser tools. If you're doing this regularly, it's worth having.

But the most important thing I took from that Thursday night isn't about tools at all. It's about diagnosis. The people who fail at PDF compression are usually the ones who drag a file into a compressor and expect magic. The people who succeed spend ten minutes understanding what's making the file heavy before they touch a single setting.

Know what you're compressing. Split before you compress if the content is heterogeneous. Check the output before you send it. And next time, build the document with the delivery format in mind from page one.

That last one is advice I give myself every project and follow maybe sixty percent of the time. Progress is progress.