Compressing a PDF for Email Attachments: A Professional's Guide

Why the Attachment Was Rejected

Short answer: The combined email size exceeded the server's transmission limit after encoding overhead was applied.

Explanation: Email systems do not transmit binary files directly. Attachments are converted into plain text using MIME encoding (Base64) before transmission. This encoding increases the size of any attachment by approximately 33% during transit.

MIME ENCODING OVERHEAD
 ┌───────────────────────┐       ┌────────────────────────┐       ┌──────────────────────┐
 │ Original File         │       │ MIME Encoding (Base64) │       │ Final Email Size     │
 │ (On Disk)             │ ───➔ │ +33% Overhead Added    │ ───➔ │ (Over the Wire)      │
 │ 18MB PDF              │       │ ~6MB Overhead          │       │ ~24MB Total          │
 └───────────────────────┘       └────────────────────────┘       └──────────────────────┘

This matters because email server limits apply to the complete encoded message, not to the file sitting on your desk. A file that is 24MB on your drive becomes approximately 32MB as an encoded email message, well over both limits.

Evidence: This transmission overhead is defined in RFC 2045 (MIME). It is not a quirk of a particular email provider — it is a fundamental property of how email transmission works across the internet. Google, Microsoft, and all major providers enforce their limits against the encoded size.

The Cross-Provider Problem

Short answer: Your attachment may pass Gmail's outbound check but still be rejected by the recipient's Exchange server.

Explanation: Gmail and Microsoft Exchange handle limits differently. Gmail evaluates the message at the outbound stage when you send. Exchange often re-evaluates the message at the inbound stage when it arrives. A corporate Exchange server with a 20MB inbound limit will silently bounce a message from Gmail — even though Gmail allowed you to send it — because the message exceeded the Exchange limit at arrival.

The sender sees their email as "delivered." The recipient never receives it. No error is displayed on either side in many configurations.

Here is a breakdown of common provider limits:

Evidence: This cross-server bounce behaviour is a known characteristic of differing SMTP server policies between consumer (Gmail, Yahoo) and enterprise (Exchange, O365) providers.

The Safe Target: Under 18MB on Disk

Action: Before attaching any file, confirm its size on disk is under 18MB. This provides sufficient margin against MIME encoding overhead for both Gmail's 25MB limit and Exchange's 20MB limit.

Compression checklist:

What to Do If 18MB Is Not Achievable

Some documents — particularly scanned files with high-resolution images — will not compress below 18MB without unacceptable quality loss.

Diagnostic Cause: Scanned PDFs are essentially large raster images embedded in a PDF wrapper. Because they contain no vector text, the compressor must aggressively downsample the images, which degrades legibility before the file size drops sufficiently. File hosting services bypass this, but relying on third-party cloud links breaks professional email chains and may trigger spam filters.

Action (Intelligent Pivot): When compression degrades readability, you must rely on structural modification instead of compression.

• Split the document: Since the limitation is per-email, divide the PDF into logical sections (e.g., Chapters 1-3, Chapters 4-6) and send them as separate emails.

Verification