How to compress a PDF for an email attachment

The real attachment size limits in 2026

Gmail, Outlook.com and most consumer mail providers allow 25 MB per message. Corporate Exchange and Google Workspace tenants often lower that to 10 MB, and a few organizations cap at 5 MB. The receiving server's limit is the smaller of the two: if you send 18 MB to a friend on a 5 MB tenant, the message will bounce.

Before you start compressing, look up the receiving mailbox's limit. There is no point shrinking to 8 MB if the destination caps at 5 MB.

What makes a PDF large

A PDF's size is mostly the sum of its images. A 300dpi A4 colour scan is around 1 MB per page. A 600dpi scan with no compression can hit 5–8 MB per page. Text and vector content are tiny by comparison. A 200-page book scanned at high quality can be 200 MB; the same book as searchable text is under 5 MB.

Knowing the dominant content tells you which compression lever to pull. If images dominate, recompress the images. If a single hi-res photo dominates, downsample that one image. If the document is mostly text, recompression will not help — you have a different problem (a scan without OCR).

Three compression strategies, ordered by impact

Try them in order. Stop at the first one that gets you under the limit.

• Recompress images: replace high-quality JPEGs with medium-quality JPEGs, or downsample images above 200dpi. The file shrinks dramatically; visible quality loss is minimal at 150–200dpi for screen reading.
• Downsample the raster: if the document is a scan, 150dpi greyscale is enough for text and reduces size by 4–6×.
• Strip redundant data: remove embedded fonts you do not need, drop XMP metadata, and (only for screen reading) flatten form fields. Each step is small but adds up.

How to compress a PDF in your browser

PdfWiseAI's Compress PDF tool runs locally. The result is a new file; the original is not modified.

• Open Compress PDF and drop the file you need to shrink.
• Pick a target size (for email) or a target quality (for archival).
• Download the compressed file. Open it and skim a few pages before sending.
• If the document is a scan, run OCR after compression to keep the text searchable — compression can flatten some metadata.

What not to do

Do not run a document through five different compressors in sequence. Each one re-encodes images and you can end up with cumulative artefacts (banding, ringing, double-JPEG). One good pass beats five cheap ones.

Do not flatten a tagged document just to save a few kilobytes. The accessibility cost is real and not reversible without re-tagging. If size is the issue, recompress images instead.

When to share a link instead of a file

If the document is large and the recipient is on a modern mail platform, consider sharing a link to a stored copy (Drive, OneDrive, Dropbox) instead of an attachment. The recipient gets a clickable preview, the mail message stays small, and you keep the original on a service with proper version history.

How to choose a target size without trial and error

A rough rule of thumb gets you to the right order of magnitude on the first try. For a 10-page text-heavy document with one or two embedded images, target 1–2 MB. For a 30-page report with mixed content, target 3–5 MB. For a 100-page scanned document, target 5–10 MB. For a 200+ page book, you are looking at 8–15 MB and you should consider sharing a link.

If the document is mostly images, the target is dominated by the images. A4 colour at 200dpi is roughly 300 KB per page after moderate JPEG compression. A4 greyscale at 150dpi is roughly 100 KB per page. If your pages are bigger than that, you are looking at 300dpi or uncompressed scans and the savings from a single compression pass will be substantial.

If the document is mostly text, the size comes from a few outsize assets — a hi-res photo on the cover, a few high-fidelity charts, a few embedded fonts. Identify the largest assets by running `pdfimages -list` (Poppler) or by opening the file in a tool that lists object sizes. Compress or downsample those assets specifically, leave the rest alone, and you will get most of the size reduction with almost no visible quality loss.

DPI, JPEG quality and the visible-quality threshold

Two parameters control the bulk of the size: the resolution (DPI) and the JPEG quality factor. Both are tunable, and the right values depend on how the document will be read.

For screen reading on a typical monitor, 150dpi is enough. The monitor is around 100dpi, so 150dpi is a small oversample that gives the text crisp edges without spending bytes on detail the eye cannot see. For a printed copy on a typical office printer, 300dpi is the floor. Below 300dpi, text edges start to show stair-stepping on letterheads and small fonts.

JPEG quality is a 0–100 scale. Below 60, the artefacts are visible around text and sharp edges. Between 60 and 80, the artefacts are imperceptible on screen and barely perceptible on print. Above 80, the file gets bigger fast for diminishing returns. The sweet spot for most email-bound documents is JPEG quality 70–75 at 150dpi.

For greyscale scans, the same rules apply with the simplification that JPEG quality matters more (because the eye is more sensitive to greyscale banding than to colour artefacts) but the absolute file size is roughly 3× smaller than colour at the same DPI. A 100-page colour scan at 200dpi is about 30 MB; the same scan in greyscale at 200dpi is about 10 MB; in greyscale at 150dpi it is about 5 MB.

Tools and commands we recommend for the manual path

If you want to compress outside a browser tool, the open-source command-line ecosystem is mature. The combination of Ghostscript, qpdf and the Poppler tools covers most of the cases the average user encounters.

Ghostscript is the most flexible. The classic command for an email-friendly PDF is `gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dBATCH -sOutputFile=out.pdf in.pdf`. The /ebook preset targets 150dpi colour images and 300dpi greyscale, which is the right balance for screen reading and small-format print. Replace /ebook with /screen for a smaller file at lower quality, or with /printer for a higher-quality file at larger size.

qpdf is the tool for lossless operations. `qpdf --linearize in.pdf out.pdf` rewrites the file in a web-optimized form that loads page-by-page in browsers; this does not shrink the file much but it makes the loading experience snappier for a recipient who reads the PDF inline. `qpdf --object-streams=generate` rewrites the file with merged object streams, which can save 5–10% without touching content.

pdfimages (from Poppler) is the inspection tool. `pdfimages -list in.pdf` shows every image in the file with its size, dimensions and compression. Use it to find the dominant assets, then run them through ImageMagick or a similar tool to downsample or re-encode, and finally re-embed the smaller images with a PDF rebuilder. For one-off use, a browser tool is faster; for batch work, the command-line path scales better.

When compression cannot help

There are documents that no compression tool can shrink to email size without rendering them useless. The two common cases are: a very large embedded font collection (for example, a 50 MB CIDFont set from a print house) and a document with hundreds of high-resolution photographs that are part of the visible content (a portfolio, a product catalogue). In both cases, the dominant size is content, not encoding overhead.

For font-heavy documents, the fix is to subset the fonts to only the glyphs the document actually uses. A 50 MB font set typically has hundreds of glyphs the document never touches; subsetting usually brings the embedded font payload down to under 1 MB without changing the visible output. Most PDF tools do not expose this as a user option, so a Ghostscript or qpdf pass is needed.

For photograph-heavy documents, the fix is to resize the photographs to the resolution needed for the destination. A photo at 600dpi for print should be 200dpi for email. A photo that is 4000×3000 pixels should be 1600×1200 pixels for a screen-friendly PDF. The visible result on screen is identical; the file is roughly 4× smaller. The cost is the loss of print-resolution detail, which is usually acceptable when the destination is email.