How to Reduce File Size for Email Attachments on Mac

The wrong fix — attempting to compress a file type that won't shrink — wastes time without solving anything, so knowing which approach applies to your specific attachment is the real starting point.

Hitting an email attachment size limit is one of the most common file-size frustrations, and the right fix depends entirely on what's actually making your file large in the first place. Here's a practical breakdown of email size limits, when compression genuinely helps, and what to do when it doesn't.

Why this problem still exists despite widespread fast internet

It's fair to wonder why email attachment limits persist at all in an era of otherwise fast, reliable internet connections. The constraint isn't really about connection speed — it's about email infrastructure itself, which was designed decades ago around assumptions of small, text-based messages, and mail servers still allocate storage and processing resources per message with those original assumptions baked into their architecture. Raising limits significantly would require meaningful infrastructure changes across an enormous, decentralized global email system, which is a large part of why the practical limits have stayed roughly similar for years even as connection speeds and storage costs have both improved dramatically elsewhere.

Common email attachment size limits

Most major email providers cap individual attachments around 25MB — Gmail and Outlook.com both use this figure, though the exact number and how it's enforced (per attachment, or per total email including all attachments combined) varies somewhat by provider. Some corporate email systems set considerably lower limits, sometimes 10MB or less, particularly for older or more conservatively configured mail servers. Checking your specific provider's actual limit before assuming a fix is needed is worth doing first, since assuming a limit that doesn't match reality wastes effort solving a problem that may not exist for your specific situation.

Does compressing the file actually help?

This depends entirely on what type of file you're trying to send, and this is the single most important thing to understand before spending time compressing anything. If you're attaching documents, spreadsheets, presentations, or other text-heavy content, compression genuinely helps — often reducing the file size substantially, sometimes enough on its own to clear a size limit that the uncompressed file exceeded. If you're attaching photos, videos, or audio, compression barely helps at all, for reasons covered in detail in our guide on why compressed files sometimes don't shrink — these formats are already internally compressed, leaving little to no additional redundancy for archive compression to find and remove.

For documents and text-heavy files: compress with 7Z

If your oversized attachment is genuinely compressible content, 7Z at a high compression setting typically achieves better size reduction than ZIP for the same content, thanks to its more efficient LZMA2 algorithm. Compress the file, check the resulting size against your email provider's limit, and attach the compressed archive instead of the original file. This single step resolves the majority of cases where the original problem was a large but genuinely compressible document.

For photos and videos: compression won't help, but other options will

If archive compression barely shrinks your photo or video attachment, that's expected behavior, not a sign the compression tool failed — see the linked guide above for the full explanation. For media specifically, your realistic options are different: reduce the media's own resolution or quality (accepting a real, if often minor, quality tradeoff, unlike lossless archive compression), or use a cloud storage link instead of a direct attachment, which sidesteps the size limit entirely since you're sharing a link rather than transmitting the actual file through the email system.

Using cloud storage links instead of attachments

For files that genuinely can't be reduced enough through compression — large videos, or already-compressed content of any kind — uploading to a cloud storage service (iCloud Drive, Dropbox, Google Drive) and sharing a download link instead of attaching the file directly bypasses email size limits entirely, since the file itself never actually passes through the email system. This is increasingly the standard approach for large or media-heavy content specifically because it sidesteps the fundamental limitation rather than fighting against it.

Combining multiple smaller attachments into one compressed archive

If you're sending several smaller files that individually clear the size limit but collectively exceed it when attached together, bundling them into one compressed archive (see our guide on combining multiple files into one ZIP) both simplifies the email to one attachment instead of several, and — for compressible content — can bring the combined total under the limit even when the sum of the uncompressed originals wouldn't have fit.

A realistic scenario: sending a folder of scanned documents

Picture scanning a stack of paper documents into a folder of individual PDF files, then trying to email the whole folder to someone. Scanned PDFs, especially at higher scan resolutions, can be surprisingly large individually, and a folder of them attached together frequently exceeds typical email limits. Compressing the folder into a 7Z archive at a high setting often shrinks scanned document PDFs meaningfully, since PDF content (particularly text-heavy or moderately-resolution scanned pages) retains real compressible redundancy, unlike a photo or video file — this is a case where archive compression genuinely earns its keep rather than a case better solved through a cloud link.

Checking your result before sending

After compressing, always verify the resulting file size against your email provider's actual limit before attaching — check the file's properties in Finder (Cmd+I, or "Get Info") for the exact size. This avoids the frustrating experience of an email bouncing back after sending, particularly for attachments close to the limit where a few extra megabytes matter.

Understanding the 33% encoding overhead in more detail

This detail trips people up often enough to be worth explaining properly. Email systems don't transmit binary attachment data directly — they encode it into a text-safe format (typically Base64) for compatibility with email protocols originally designed for plain text. This encoding process increases the effective transmitted size by roughly one-third compared to the original file size. Practically, this means a file sitting right at a stated 25MB limit may actually fail to send, since the encoded version transmitted behind the scenes is meaningfully larger than the raw file size you see in Finder. Building in a genuine margin — targeting well under the stated limit rather than right up against it — avoids this specific, commonly misunderstood failure mode.

Comparing compression against media-specific size reduction

For attachments where the bulk of the size comes from photos or video specifically, it's worth understanding that a different category of tool — one that re-encodes the media itself at a different quality or resolution setting — is the correct solution, not archive compression. This is a fundamentally different process: it actually changes the pixel or audio data through re-encoding (a real, if often visually minor, quality tradeoff), rather than losslessly repackaging the existing data the way ZIP or 7Z compression does. If you regularly need to reduce photo or video file sizes specifically for email or other size-limited sharing, a dedicated media compression tool addresses that need directly, while an archive tool remains the right choice specifically for documents, code, and other genuinely compressible content.

Troubleshooting

• Compressed file is still too large: the content is likely already-compressed media — switch to a cloud storage link instead of continuing to try compression.
• Email bounces even though the attachment seems under the stated limit: some providers count encoding overhead (attachments are typically encoded in a way that increases their effective size by roughly 33% during transmission) — leave meaningful margin below the stated limit rather than compressing to just barely under it.
• Recipient's email provider has a different, lower limit than yours: when in doubt, especially for external recipients on unknown email systems, a cloud storage link avoids this uncertainty entirely.

Frequently asked questions

Why does my email client sometimes automatically convert an attachment to a cloud link? Some email clients (particularly Gmail with Google Drive integration) automatically detect an oversized attachment and offer to upload it to cloud storage instead, handling exactly this problem transparently without you needing to manually compress or upload anything yourself.

Does compressing an attachment affect its quality? No — archive compression (ZIP, 7Z) is lossless, meaning the file is restored byte-for-byte identical upon extraction. Any quality loss would come specifically from reducing the media's own resolution or quality settings, a separate and different process from archive compression.

Is it rude or unprofessional to send a cloud link instead of a direct attachment? Not anymore — cloud storage links have become a standard, widely accepted method for sharing large files professionally, particularly once a file exceeds what direct attachment can reasonably handle.

The bottom line

Compression genuinely helps for documents and text-heavy content but does little for photos and video — knowing which category your file falls into determines whether compressing or switching to a cloud link is the right fix. Unzipr handles the compression side with adjustable levels and 7Z support, so document-heavy attachments get the maximum size reduction available before you resort to a cloud link, with instant preview to confirm the compressed result before sending.