Why Your Pitch Deck PDF Looks Blurry—and How to Reduce Its Size Without Losing the Point
Why Your Pitch Deck PDF Looks Blurry—and How to Reduce Its Size Without Losing the Point
A deck that is too heavy to send and too soft to read is usually two problems riding in on one file. The weight came from somewhere. The softness came from somewhere else. Export settings are implicated in both, which is why everyone reaches for them first, and why that often makes matters worse: harsher compression on a file that was already failing upstream removes weight and detail together, and you end up with a smaller document that no longer proves what it was built to prove.
Here is the shape of the answer. Keep the untouched deck, the original image files, and one full-quality export. Pick a single detail your argument depends on. Look at that detail in four places — the original file at 100%, the placed image on the slide, the first PDF, and the reduced copy. Compare the two PDFs in the same viewer at the same zoom; the original file and the placed image are each judged in their own tool, at their own scale. Where it disappears tells you which repair to make. If it never existed in the original file, no export setting will find it.
Only after that does compression become a conversation worth having.
Keep a baseline and trace one damaged detail
Before you change anything, separate your files. At minimum you want:
- the deck itself
- the original image files, at whatever resolution you have them
- a first export made at the highest image quality your tool offers, even if the result is too big to send
- each reduced candidate, saved as a new file
Never overwrite the full-quality export. If deck_full.pdf is gone, you lose the ability to tell whether the small file dropped something the big file had, or the big file was broken from the start. The baseline exists so you have an honest ceiling to compare against — not because you intend to send it.
Then choose the detail to trace. Not the cover. The cover is usually the least informative page in a deck: a title, a name, maybe a moody still. Trace the thing a reader has to be able to see for the argument to land. A face and its expression. A location reference with one identifying feature. A small piece of type inside a photograph. The label on a prop.
Look at that detail four times:
- the original image file, opened at 100% zoom — this is the ceiling
- the image as placed on the slide, at the size the layout gives it
- the detail in the full-quality PDF
- the detail in the reduced candidate
Same viewer for steps three and four, same zoom level. This matters more than it sounds. Different viewers smooth images differently, and a viewer fitting a page into a window narrower than the page draws fewer pixels than the file holds. "Fit page" in one application and 200% in another is not a comparison; it's two different pictures. Zoom in until you can see individual pixels or JPEG blocks, then return to the size a real reader will use and judge there. If softness vanishes when you zoom in and returns when you zoom out, you may be looking at a display condition rather than a file condition. Also give the viewer a moment: what looks blurry mid-scroll is often just a redraw in progress.
An invented deck to trace through
Here is a stipulation, not a measurement: a four-page deck for a short film, 13.33 by 7.5 inches per page, exported to PDF. Page 3 is image-led — a photograph of a cassette recorder placed 8 inches wide, where the argument depends on the recorder being the same model the script names, and the only visible evidence is a small badge on the front. Page 4 is text-led: a paragraph of body copy, a one-line source credit under a small reference still, a bookmark to an appendix, and a link to a test clip.
The source photograph, recorder.jpg, is 800 by 600 pixels. Open it at 100% and the badge is 16 pixels wide. Sixteen pixels cannot render a model number legibly at any size. That is the whole verdict, and everything downstream is faithfully reproducing it.
Solve the arithmetic for the export and it holds. View the page fit to a window that gives it about 1,000 pixels of width: 1,000 divided by 13.33 inches is roughly 75 pixels per inch. The 8-inch image draws at 600 pixels, downsampled from 800, which is fine — no pixels are being invented. The badge is 2% of the photograph's width, so it draws at roughly 12 pixels. Still unreadable.
The reduced copy does not improve on that: fewer pixels if the reduction downsampled, coarser encoding of the same pixels if it only recompressed. The numbers here are chosen so you can check the method with your own page; the point is the arithmetic, not the figures.
Choose the repair at the point where detail disappears
There are three places a detail can go, and the entire method is in keeping them apart.
It was never in the original file. Open the source at 100%. If the badge or the face is already a smudge there, it will be a smudge everywhere downstream, and raising export quality only makes the smudge larger. This is the branch people skip, because the honest repair is editorial rather than technical. Get a better file. Choose a different reference. Crop to the part that carries the meaning — accepting that a crop shows the same few pixels larger rather than clearer, which is often not good enough. Or, frequently the best answer, say the thing in type: a legible line of copy beside the picture does the job the illegible badge was failing to do.
The original is fine and the placement is fine, but the first PDF is soft. That's an export problem, and it's worth checking whether your export is downsampling to a target below what the placement needs.
Only the reduced copy fails. That's the reduction step.
One version of the second branch deserves a warning, because it's the case where shrinking the placed image is the right move and it looks like the wrong one. If a small image has been stretched across the page — 400 pixels of source spread over 8 inches, say — the export is upsampling it and the result is soft everywhere. Placing it at 5 inches instead brings it close to one-to-one and it goes crisp. That's a legitimate use of reducing placed size. It is the opposite of the situation in the invented deck above, where the image is already being downsampled and shrinking it just makes the badge smaller. Same action, opposite consequence; the four-checkpoint comparison is what tells you which one you're in.
Now the distinction that carries most of the weight here: downsampling and compression are not two names for one slider.
Downsampling throws pixels away. The stored image is rewritten at smaller dimensions, so the file holds fewer samples — less real detail for anyone who zooms in, and less weight. Compression re-encodes the image at the same dimensions, spending fewer bits on it. In one case you have fewer bricks; in the other, blurrier bricks. A single control labeled "quality" or "size" may drive both, which is exactly how they get conflated.
Adobe's Acrobat help page on PDF optimizer settings — body heading "PDF optimizer settings," page displaying an update dated 2025-09-23 — documents downsampling and compression as separate controls within its image settings. It also separates image adjustments from "Discard Objects" and "Discard User Data," noting that some of those options remove tags, multimedia, or links rather than merely re-encoding what's there. That page is help for one application, not a test of your file, and it establishes no universal resolution or size target. Its use here is narrower: the same panel that changes how images are sampled may also contain switches that remove things from the document entirely, and it's worth knowing which kind of switch you're touching before you touch it.
Change one setting on a representative page
Now you can reduce — one variable at a time.
Pick a page that contains the harder cases rather than the easiest. For most decks that means small lettering that must stay readable (a source credit, a date, a line of legal text) plus an image whose relationship to something else matters (a still with the note explaining why it's there, a map with its legend). If any page carries a link or a bookmark, use one of those. Test the page that would fail first.
Export a candidate. Change one image setting. Export again. Record the setting name and value, the resulting file size, and a yes or no on whether your chosen detail still reads. If you change three things at once and the file gets smaller, you have learned that the file got smaller. You have not learned which change did it, and the next deck starts from zero.
If you don't yet know what's making your file heavy, one throwaway test answers it: export a candidate with image quality pushed far below anything you'd send, look at how much the size moved, and then delete that file. If dropping image quality barely changes the size, your weight is somewhere else — embedded fonts, for instance, behave quite differently and need their own diagnosis. The experiment is for information, not for delivery, so keep it out of your candidates folder.
Then choose by the reader's task, not by the smallest number. There is no DPI figure or megabyte target that is right for every deck. The useful version of the question is how many pixels your detail gets where it will actually be viewed. If the whole page renders about 1,000 pixels across and the detail spans a tenth of the page width, the detail gets about 100 pixels. For a seven-character model number, that's ample. For two lines of caption inside a 40-pixel band, it isn't. That rough calculation tells you whether to worry, and roughly which setting to try next.
A deck read on a phone in an email and a deck projected in a room are not the same document, even when the bytes are identical. Decide which one you're sending before you tune for it.
Check what the smaller file lost besides pixels
A PDF is not only pictures. It can carry structure: tags a screen reader follows, bookmarks that make an appendix reachable, hyperlinks, embedded audio or video, references to files that live elsewhere. Dropping some of that is a real reduction in size. Adobe's optimizer page explicitly separates "Discard Objects" and "Discard User Data" from its image settings, which is a reason to read the switches you're about to use — not a prediction about what yours will do.
So test the functions the way you tested the detail. Click every link in the reduced copy. Jump to the bookmark. Confirm the caption's alt text survived, if the deck has any. Play the embedded clip, or confirm the external reference still resolves. This takes a minute and cannot be done by looking at a page, because a page with a dead link looks exactly like a page with a live one.
If the reduction removed a function, restore the baseline and run a narrower operation. A missing appendix link is not the price of a smaller attachment; it's a defect. Pixels are negotiable. Functions mostly aren't.
Change the delivery rather than destroy the point
Sometimes the arithmetic doesn't work. The reduced file that survives every check above is still over the limit, and the only way under is to make images unreadable. At that point, more compression is not the answer.
Two honest routes.
Deliver it differently. A link to the deck on a host you control, sent with a short note, is a different product from an attachment — decide which one the situation calls for. If a hard limit belongs to the recipient's system, you may not control the route at all, only which version travels along it.
Rebuild it small on purpose. Instead of compressing a large document until it breaks, make a version designed to be small. Recompose the image-led pages so the important image fills more of the frame — cropping to the part that carries the argument rather than stretching a small source across the space. Filling the frame helps only when the source has enough pixels for the larger placement; enlarge past that and the detail goes softer without the file getting any smaller. Drop the decorative full-bleed photographs that carry no argument; they are often a large share of the weight and none of the meaning. Set the text as text, which stays crisp at any size and costs almost nothing. Place the detail that must be legible at a size where it can be legible.
What simplification cannot do is delete evidence. If the argument is "this is what it looks like," the image is the argument, and it doesn't get to leave to save bytes. Look tests, location references, storyboard frames, performance stills — those are the pages to protect. They may be a large share of your file size, and that is not a reason to cut them; the weight to remove is in the decorative and redundant images around them.
Then open the exact file through the exact route before you choose. Not the copy on your desktop, but the one that arrived in the mail client, on the phone, in the browser viewer. Read the detail you've been tracking since the first checkpoint. Does it still say what it said?
The trade you can state out loud
The end state isn't the smallest possible file. It's a file whose size came from somewhere you can name, and a page whose necessary detail is still there.
If you started with a 40 MB export that read badly and finished with a 9 MB version that reads — the part worth keeping is which checkpoint failed and what you changed because of it. If you started with a 40 MB export that read badly and finished with a 6 MB version that reads just as badly, nothing was repaired; you simply spent the difference.
The smaller file earns its size only when the detail you chose at the beginning, and the link and the bookmark beside it, still do their work at the size your reader will actually meet them.
Frequently asked questions
Why can harsher compression make a blurry pitch deck worse?
The body treats weight and softness as separate problems. Harsher compression on a file already failing upstream can remove weight and detail together, leaving a smaller document that no longer proves what it was built to prove. The order should be to trace the damaged detail first and only then discuss compression.
How do I trace a damaged detail through the export chain?
Keep the untouched deck, the original image files, a first full-quality export, and each reduced candidate as a new file. Pick a detail the argument depends on. Look at it in the original image at 100 percent, as placed on the slide, in the full-quality PDF, and in the reduced copy. Compare the two PDFs in the same viewer at the same zoom; where the detail disappears tells you which repair to make.
What if the detail is already unreadable in the original image file?
No export setting will find it. The body says the honest repair is editorial: get a better file, choose a different reference, crop to the part that carries meaning while accepting that a crop shows the same few pixels larger rather than clearer, or say the thing in type beside the picture. If only the reduced copy fails, that is the reduction step; if the first PDF is soft, that is an export or downsampling problem.
Are downsampling and compression the same thing?
No. Downsampling throws pixels away and rewrites the stored image at smaller dimensions, so the file holds fewer samples. Compression re-encodes the image at the same dimensions and spends fewer bits on it. A single control labeled quality or size may drive both. The body cites Adobe's Acrobat help page on PDF optimizer settings as documenting them as separate controls, but also says that page is help for one application, not a test of your file or a universal target.
What should a smaller file not lose besides pixels, and when should I change delivery instead?
A PDF can carry tags, bookmarks, hyperlinks, embedded media, and external references. Click every link, jump to the bookmark, confirm alt text, play the clip, and check external references, because a page with a dead link looks like a page with a live one. If a reduction removed a function, restore the baseline and run a narrower operation. If the file still cannot meet the limit without making images unreadable, deliver it differently, such as by link, or rebuild it small on purpose; do not delete evidence. Test the exact file through the exact route.