Guide

How to reduce a PDF for email attachment limits

Updated September 2026 · A playbook for “the file will not attach”: pick a tactic from the limit and the contents, instead of mashing Compress until the type turns to mush.

Attachment errors are a logistics problem first and a compression problem second. A 40-page phone-scan packet, a 2-page tax form, and a slide deck exported as a PDF all fail for different reasons. This page is the decision tree: what limit you are under, what is inflating the file, and which job to run. The quality sliders live in Compress PDF without losing too much quality and the broader readability checklist in Compress without wrecking readability. Do not start there if you still have blank backs, a photo appendix nobody asked for, or a packet that should be two emails.

Triage by the limit you actually have

Caps change, and workplaces add their own. Treat these as approximate public / common provider caps, not as a promise from your ISP or IT ticket:

• Gmail (consumer). Attachments commonly fail around 25 MB per message. Over that, Gmail typically offers a Drive link instead of a true attachment. If the recipient’s system blocks Drive, a link is not a fix.
• Other major webmail. Outlook.com, Yahoo, and similar consumer inboxes often sit in the same ballpark (about 20–25 MB). Do not treat that as exact — the compose window’s error is the source of truth.
• Work and school mail. Many Microsoft 365 / Google Workspace tenants allow larger sends than consumer Gmail, and many do not. The recipient’s inbound cap can still bounce a message you sent “successfully.”
• Portals and forms. Government, insurance, and HR uploaders are often 5–10 MB, sometimes less. The email might accept the file; the portal will not. Use the portal’s number.
• Phones and shared mailboxes. A file that left your laptop can still fail when someone forwards it, or when a phone client refuses the download.

Write the target on a scrap of paper: “must be under 10 MB as a real attachment, not a link.” Then look at the current size. If you are at 11 MB, you need a trim. If you are at 80 MB, compression alone is the wrong first move.

Why this file is large

Open the PDF, check page count, and skim thumbnails. Size almost always comes from one of these:

• Too many pages. Duplex blanks, a scanned envelope, last year’s appendix. Deleting ten empty backs can beat any slider. See delete pages.
• One huge image section. A photo ID spread, a color brochure, or a 600 dpi phone scan of a whiteboard. The typed pages are not the problem.
• The whole file is a scan. Each page is a picture. “Compress” here means downsample those pictures, not squeeze the fonts (there are no fonts).
• A merge of several already-heavy PDFs. Re-merging after you shrink each source is cleaner than crushing the stack. See merge.
• Embedded files, attachments, or unused high-res images. A desktop optimizer can strip those; a one-slider website usually cannot tell you what it removed.

If the PDF is 800 KB and still “will not send,” you are not over an attachment cap — you are hitting a blocked type, a policy, or a different field (some forms want JPG). Do not compress a file that is already small.

Compress, split, extract, or images

Pick one primary tactic. Mixing three tactics on the same copy is how you get an unreadable 9 MB file and no master.

• Delete first, always, if pages should not travel. Blanks, duplicates, and “do not send” sheets come off the working copy. That is not optional optimization.
• Extract when the recipient only needs a range, and you must keep the long original. Extract pages into a new file; do not delete from the master to “make” that file.
• Split when the whole document is required but no single attachment may exceed the cap. Two 12 MB parts beat one 24 MB mushy file. Label parts clearly (1 of 2, page ranges in the filename).
• Compress (quality-aware) when the page set is already right and you are slightly over. One mild pass from the original. Stop at the first file that clears the limit. Settings and the zoom check are in the quality guide — this playbook will not repeat those sliders.
• Images when the destination is not a PDF at all (a “upload a picture of the receipt” box), or when one page must go as a screenshot-quality still. Use PDF to JPG/PNG. Converting every page of a 30-page contract to JPG is not an email strategy.
• Link or shared drive when the recipient can open a link and the policy allows it. That is not an attachment. Say so in the email.

Print-to-PDF as a “compress” trick is a last resort. It can turn sharp type into a page-sized image and still miss a tight portal cap. Prefer a real optimize/export, or a split.

Scenario recipes

Use the row that matches your limit and contents. Work on a duplicate every time.

1. Gmail (~25 MB) and you are at 28–40 MB. You are close. Delete junk pages. If it is a scan, one middle-quality compress from the original. If it is a merge of two reports, split by report and send two messages, or one message with two attachments if both still fit. Do not run “email (smallest)” first.
2. Gmail (~25 MB) and you are at 60 MB+. Compression will look awful before it fits. Split into parts under the cap, or extract the section they asked for. Rescan at 200–300 dpi if this is a phone photo of 40 pages; crushing 12-megapixel JPEGs is the wrong factory.
3. Portal or form at ~10 MB, file is a 15 MB clean digital PDF (real text). Pages are probably already right. Try a mild optimize that downsamples only images. If there are no photos and it is still 15 MB, look for embedded attachments or an oversized cover image — or split if the portal allows multiple uploads.
4. Portal at ~5–10 MB, file is a color scan. Delete blanks. Extract only the required pages. Then one quality-aware compress. If a single page is a huge photo, export that page as JPG and upload it separately if the form allows mixed types.
5. Recipient asked for “just the signed page.” Extract that page (and any rider that is legally part of the signature). Do not compress the whole book. Confirm the signature is still sharp at 100% zoom.
6. You must send the whole book and they cannot take a link. Split on logical breaks (chapters, “exhibits A–C”), not on random page 17. Put the range in each filename. Mention the part count in the email so nobody files part 1 as the complete packet.
7. The compose window accepts the file but the bounce comes back later. Their inbound cap is smaller than yours. Split or compress to a noticeably lower size (for example, aim well under 10 MB if you do not know their number), or ask what they can receive. Guessing a specific ISP quota is a waste of time.

If the PDF is a filled form that must not stay editable, flatten the already-sized file last — flattening first, then compressing, can rasterize fields twice. See flatten before email.

How to send the result

• Open the outgoing file on your computer. Page count, first page, last page, and a signature page if any.
• Check size on disk, not the size an optimizer advertised in a browser tab.
• Attach and watch the client’s own size warning. That warning beats any table on this page.
• If you split, attach every part or say which part follows. Do not rely on “as discussed.”
• If you used a link, say that it is a link, who can open it, and how long it lasts if you know.
• Keep the master. Attachment copies get forwarded and compressed again by the next person.

There is no honest mode that turns an 80 MB phone-scan binder into a crisp 2 MB email with “no quality loss.” The playbook is: send fewer pages, or send more files, or accept a milder shrink that still reads. Two readable messages beat one rejected one.