How to reduce image size before you convert to PDF

You photograph ten pages, convert them to a PDF, and end up with a 60 MB file that Gmail will not send and the application portal will not accept. The usual response is to compress the PDF afterwards, which works — but it is the second-best fix, applied after the problem has already been baked into the file.

The reason is arithmetic. A current phone camera produces images with roughly three times as many pixels as an A4 page can display at full print quality, and five or six times what anyone reading on a screen will ever see. That excess gets embedded into the PDF, carried around, uploaded, downloaded — and then mostly discarded by the compression you run at the end. Removing it at the start produces a smaller file, a faster conversion and, frequently, a better-looking result.

Why resize before rather than compress after

Both routes end with a smaller PDF. They do not end with the same PDF.

The distinction that matters is what is being thrown away. Downscaling removes resolution that exceeded what the page could show in the first place — genuinely surplus data. Lossy compression removes information from the pixels that remain, which is why over-compressed pages get that faint smeared look around lettering. Discarding the surplus first means the compression you apply afterwards, if you still need any, has far less work to do.

The arithmetic: what size do you actually need?

One calculation answers the whole question. Pixels divided by inches gives you DPI — dots per inch — which is the only number that determines whether a page looks sharp:

DPI = image width in pixels ÷ page width in inches

An A4 page is 8.27 inches wide; US Letter is 8.5. A typical 12-megapixel phone photograph is 4032 pixels on its long edge. Put that on an A4 portrait page and you get 4032 ÷ 8.27 ≈ 487 DPI.

That is roughly 1.6 times the resolution a professional printing press uses and about five times what a screen can resolve. Everything above 300 DPI is invisible on paper. Everything above about 150 is invisible on screen. You are carrying it, uploading it, and paying for it in file size for no return at all.

Reversing the calculation gives you the target: pixels needed = page width in inches × the DPI you want. For an A4 page at 150 DPI that is 8.27 × 150 ≈ 1240 pixels wide. Going from 4032 to 1240 pixels cuts the pixel count by about 90%, and on a page that will be read on a screen the difference is invisible.

Target dimensions worth memorising

Full-page images on a portrait page, rounded to sensible numbers:

For most everyday purposes — a form, a receipt, proof of address, an expense claim, anything read on a screen — 150 DPI is genuinely enough, and 200 is a comfortable default when you are not certain whether it will be printed. Ten pages at 150 DPI produce a PDF of a few megabytes rather than sixty, with no visible difference to the reader.

Sizes above are for an image filling the page. An image occupying half the page width needs half the pixels for the same apparent sharpness, which is worth remembering when you are placing photographs into a report rather than converting full pages.

How to resize on each platform

iPhone and iPad

iOS has no built-in resize control, which is a long-standing gap. There is one workaround that requires nothing extra: open the image in Photos, tap Edit, use Crop, and export — cropping reduces pixel count directly. Otherwise the reliable route is Shortcuts: create a shortcut using the Resize Image action set to a longest-edge value of 1600 pixels, and run it on any photo from the share sheet. It is fifteen minutes to set up once and then a two-tap operation forever.

Android

Google Photos can export at reduced size when sharing, and most manufacturer galleries include a resize option in the image details or the share menu — Samsung's Gallery has one under the ⋮ menu. Behaviour varies by skin and version, so check the exported dimensions once before trusting it for a batch.

Windows

Select the images in File Explorer, right-click and choose Resize pictures if you have PowerToys installed — it handles batches, writes copies rather than overwriting, and is the best option on Windows by a distance. Without PowerToys, open a single image in Paint and use Resize with "Maintain aspect ratio" ticked; set Pixels rather than Percentage and enter your target width.

macOS

Select the images in Finder, open them all in Preview, select all in the sidebar, then Tools → Adjust Size. Set the width, keep "Scale proportionally" ticked, and save — Preview applies it to every selected image at once. This is the cleanest built-in batch resize on any platform.

Dimensions versus quality setting

Two separate dials control JPG file size and they are easy to confuse. Dimensions are how many pixels there are. Quality is how much detail the compression keeps within those pixels. Reducing either shrinks the file, and they fail in completely different ways.

Reducing dimensions degrades gracefully: the image gets smaller, stays clean, and the only limit is the point at which text becomes too small to read. Reducing quality degrades visibly: the image stays the same size and acquires blocky halos around every hard edge, which on a page of text is exactly where the eye is looking.

So the order is: get the dimensions right first, then leave quality reasonably high — 80 to 85% is the sweet spot for document photographs. A 1240-pixel-wide image at 85% quality looks markedly better than a 4032-pixel image at 30% quality, and the file is smaller.

One caveat for phone photographs: every JPG save re-compresses, so resizing a photo that has already been through several rounds of saving and re-sharing compounds damage that is already there. Work from the original in your camera roll rather than the copy that came back through a messaging app.

When not to shrink

Shrinking first is right most of the time and wrong in a few specific cases. Getting these wrong costs more than the megabytes saved.

• Anything going through OCR. Character recognition needs detail at the level of individual letters, and 300 DPI on the text is the practical floor. Below that, accuracy falls off quickly and the errors are silent — a searchable PDF whose text layer is wrong is worse than one with no text layer, because searches fail without telling you why.
• Small print and fine detail. Contract footnotes, meter readings, serial numbers, handwriting. Zoom to the smallest thing on the page that matters and make sure it survives the resize.
• Anything that will be printed at full size. A poster, a certificate, a photograph for framing. Screen resolution is a quarter of print resolution, and the gap is obvious on paper.
• Legal, medical or archival submissions. These frequently specify a minimum resolution outright, and a downscaled file can be rejected on that basis regardless of how it looks.
• Originals you cannot re-take. If the document has been returned, the meeting is over or the damage has been repaired, keep the full-resolution version somewhere and shrink only the copy you are sending.

The general test: can you re-photograph this if the shrunken version turns out to be inadequate? If yes, shrink freely. If no, keep the original and shrink a copy.

The order of operations

Sequence matters here, because several of these steps degrade the input to the next one.

If the PDF already exists

All of the above assumes you still have the images. Often you do not — someone sent you a 90 MB PDF, or you built it a month ago and the photographs are gone.

In that case Compress PDF is the right tool and does the equivalent job from the other end: it re-encodes the embedded images and, where they are absurdly oversized for their page, downsamples them. The result is usually a large reduction, because the surplus resolution described above is exactly what it finds. Under 10 MB is a safe general target and under 5 MB for older institutional portals, which are frequently stricter than their instructions admit.

Two follow-ups when compression alone is not enough. Split PDF divides an oversized document into parts that can be sent separately, which is often the pragmatic answer for a long scanned report. And if the file is slow and unwieldy rather than merely large, size may not be the real problem at all — why some PDFs are slow to open covers the cases where an 8 MB file behaves worse than a 40 MB one.

Frequently asked questions