The short version

Gmail's 25MB cap covers the base64-encoded attachment, not the file on your disk. Encoding inflates files by about 37 percent, so the working limit is around 18MB. Compress the PDF, do not use Drive links unless you have to, and aim tighter if the recipient reads mail on a corporate server.

Compress a PDF for Gmail targets exactly 18MB. Drop your file in, wait a few seconds, done.

A PDF that opens fine, previews fine, sits at 22MB on your disk, and Gmail refuses to send it. The error message points at a 25MB limit that your file is clearly under. Something is off, and it is not you.

What is off is that Gmail measures the wrong number. The 25MB in every help article describes the size of the attachment after it has been encoded for transit, and that encoding process makes files bigger. Understanding that one detail changes everything about how you prepare an attachment.

The 25MB myth, explained in numbers

Email attachments cannot be sent as raw binary. The protocol that carries them, SMTP, was built in the 1980s for text messages and only understands a limited set of characters. To ship a PDF through it, the file has to be converted into a text-friendly format called base64.

Base64 encoding uses 4 characters to represent every 3 bytes of the original file. That is a fixed 33 percent expansion, plus a bit more once line breaks and MIME headers are added on top. The final overhead lands around 37 percent.

Stated limit
25 MB

What Gmail's help article promises. Applies to the encoded payload on the wire.

Encoding overhead
+37%

Base64 adds a third to every attachment. Bigger files, bigger inflation.

Working ceiling
~18 MB

Raw file size that reliably sends without hitting the cap after inflation.

Do the arithmetic on your 22MB PDF. Encoded, it becomes roughly 30MB. Gmail's server compares that number against 25MB and rejects the message. The file did not grow. The measurement finally caught up with what Gmail was actually checking.

Why nobody tells you this
The 25MB number is technically correct from Gmail's point of view. It measures what its own servers process, which is the encoded stream. The problem is that every user thinks in raw file size, and no help article bridges the gap. Every major provider (Outlook, iCloud, Yahoo) works the same way.

Fix one: compress the PDF to fit

The right target depends on what kind of file you are shipping. Most business documents fit under 18MB after a single compression pass with no visible quality loss. A folder of scanned pages usually needs a heavier hand. Photograph-based PDFs sit somewhere in between.

Try it

Will your attachment send?

Enter your file size to see the encoded figure Gmail measures, and which inboxes accept it.

1

Open a compressor that targets a specific size

Generic "compress PDF" tools give you one output at a fixed quality. A size-targeted compressor tries multiple quality passes and stops as soon as the file fits.

2

Drop the file, pick 18MB

The tool renders each page at a starting resolution, embeds as JPEG at high quality, and checks the total size. Too big, and it steps down one attempt at a time.

3

Verify readability before sending

Open the compressed file, zoom to actual size on the pages with the smallest text. If it reads clearly, you are done. If not, you have room to try 20MB (still under the wire limit for most Gmail users).

Keep the original
Never overwrite the source file with the compressed copy. If the output turns out too soft, you want the option to try again from clean input, not compress a compressed file. Compressing twice stacks the losses and rarely improves size much.

Compress vs Google Drive link

When your file is over the limit, Gmail offers a shortcut: upload it to Google Drive and send a link instead. This works, and Google would rather you took that path. But it is worth understanding what changes for the person on the other end.

Compressed PDF

Behaves like every other email

  • Arrives as an attachment with a preview icon
  • Downloads to the recipient's usual folder
  • Survives corporate email gateways and forwards
  • Works forever, independent of your Drive
  • No permission dialogs, no sign-in prompts
Drive link fallback

Changes the recipient's experience

  • Shows as a link, not an attachment
  • Sometimes flagged as suspicious by spam filters
  • Requires the recipient to be signed into a Google account
  • Corporate gateways may strip the link preview
  • Breaks if you ever move or delete the file

Neither is wrong. Compression is the default when the file is compressible and the recipient is anywhere outside your organization. Drive links are the fallback for anything genuinely too large to shrink, or for internal sharing where everyone already lives in the same Google Workspace.

The recipient's server matters

Gmail's limit is not the only limit in the chain. Every mail server your attachment passes through applies its own cap, and the tightest one wins. Corporate inboxes are usually where things fail.

Typical inbound capsReal limits by recipient type
  • Personal Gmail, Yahoo, iCloud~18MB raw
  • Google Workspace (business)~18MB raw
  • Microsoft 365 corporate~20MB raw
  • Exchange (self-hosted)Often 10MB
  • Legacy corporate gatewayOften 7 to 10MB
  • University mail systemsUsually 10 to 25MB

The rule of thumb: if you know the recipient sits behind a corporate address, aim for under 10MB instead of 18MB. Our under-10MB compressor targets that lower ceiling with the same iterative approach.

Silent bounces
Corporate gateways that reject oversized attachments do not always send a bounce message back. Your email disappears into the recipient's spam log without anyone noticing. If a large file has to reach a corporate inbox and you do not hear back, do not assume it arrived. Ping the recipient.

When compression will not be enough

Some PDFs cannot shrink to 18MB and stay legible. A hundred-page colour photograph book is one example. Full-resolution architecture drawings are another. When you hit that wall, you have three real options.

Split the file

Two 15MB emails almost always beat one 30MB email that bounces. Break the PDF into a "part 1 of 2" and "part 2 of 2" using our Split PDF tool. Recipients can save both and combine later if they want, or read them in sequence. Common in legal work, where discovery productions are routinely delivered as numbered batches.

Send via a link that you control

Google Drive, OneDrive, Dropbox, iCloud Drive: each offers link-based sharing. The email carries a URL instead of the file. Downsides: some recipients treat cloud links as suspicious, some gateways strip previews, and files break if you ever move or delete them. Upsides: no size limit worth mentioning, and delivery is instant.

Use a file-transfer service

WeTransfer, Send Anywhere, and Swiss Transfer let you send large files as time-limited links without needing an account. Good for one-off large deliveries. Not appropriate for anything you want indexed in the recipient's inbox permanently, since the link expires.

Habits that stop the problem before it happens

Once you understand why big attachments fail, you can build small habits that keep files under the ceiling without thinking about it.

Four habits

Compress at export. When saving PDFs from Word, Pages, or InDesign, pick the "smallest file" or "optimized" preset. It halves file size before it ever hits your inbox.

Scan in greyscale. Colour scans are three times the size of greyscale scans of the same page. Unless you actually need colour, greyscale is the right choice for documents.

Aim below the ceiling. Landing at 17MB when the limit is 18MB leaves no headroom for base64 rounding. Landing at 10MB does. Room to breathe survives more mail systems.

Ask before assuming. If you are about to send a big file to a corporate recipient for the first time, one message beforehand ("is 18MB okay for your inbox?") saves the roundtrip when it bounces silently.

Compress a PDF for Gmail in your browser

Auto-target 18MB. Nothing uploaded, nothing tracked. Runs on your device via WebAssembly.

Open the tool

Common questions

Details that come up after the first bounce.

01What is Gmail's real attachment size limit?

Gmail advertises 25MB. The reliable working ceiling is about 18MB of raw file size, because attachments get base64-encoded during transit and that adds roughly 37 percent overhead. Files at 20MB or more raw will often send, but 18MB is the number that clears almost every case.

02Why does my 22MB PDF fail when Gmail claims 25MB?

After base64 encoding, that 22MB file becomes about 30MB on the wire. Gmail's cap applies to the encoded size, not the raw file. Your 22MB attachment is technically 30MB by the time Gmail measures it, past the ceiling.

03Will Gmail's automatic Drive link save me?

It bypasses the size cap but changes what your recipient sees. The message arrives with a link icon instead of a paperclip. Some corporate spam filters treat oversized Drive links as suspicious. The file breaks if you ever move or delete it from your Drive. Compression, when it works, keeps the experience identical to a normal email.

04How much can compression realistically shrink a PDF?

Scanned documents and image-heavy PDFs often drop by 60 to 90 percent without visible quality loss. Text-based PDFs exported from Word or Google Docs shrink far less, sometimes only 10 or 15 percent, because they were already small. If a text-only PDF is over 18MB, something unusual is inside (embedded fonts, uncompressed images), and you may need to re-export from the source with better settings.

05What if the recipient is on corporate email?

Aim for under 10MB. Corporate Exchange servers and security gateways commonly recap incoming attachments at 10 to 15MB. Even if your side accepts a 20MB send, the recipient's server may quietly reject it, and corporate gateways do not always bounce the message back.

06Does PDFslime upload my file to compress it?

No. Compression runs entirely in your browser using WebAssembly. Files are read into local memory and never sent to a server. Close the tab and the data is gone. This matters when the PDF contains anything you would not want on a stranger's server, which is most business documents.