Resize each photograph to 1600 pixels on its long edge and encode at quality 80. That produces a file of roughly 100 KB to 250 KB, looks correct on any screen the recipient will use, and lets you attach twenty photographs inside a 10 MB limit.
Two facts make this necessary. Attachment limits are lower than they appear, and photographs straight from a phone are ten to thirty times larger than an email needs.
The limits are lower than the stated number
Gmail accepts attachments up to 25 MB. Outlook.com accepts 20 MB. Corporate mail servers are frequently configured to 10 MB, and some to 5 MB.
The limit that applies is the smaller of the sending and receiving systems, and you cannot see the recipient's. A message that leaves your outbox successfully can be rejected several hops later, sometimes silently. Treating 10 MB as the practical ceiling avoids the entire class of problem.
Attachments are inflated by about a third in transit
This is the part almost nobody accounts for, and it is why a 19 MB set of photographs bounces off a 20 MB limit.
Email was specified for 7-bit text. Binary attachments cannot travel as-is, so they are encoded in base64, which represents every 3 bytes of binary data as 4 characters of text. That is a 33% increase before anything else. MIME then inserts a line break every 76 characters, adding roughly 2.7% more.
The working figure is 1.37×. A 10 MB folder of photographs becomes about 13.7 MB on the wire. The limit applies to the encoded size, not to what your file manager reports.
| Stated limit | Actual budget for files |
|---|---|
| 25 MB (Gmail) | about 18 MB |
| 20 MB (Outlook.com) | about 14.5 MB |
| 10 MB (common corporate) | about 7 MB |
| 5 MB (restrictive) | about 3.5 MB |
Resize first, then compress
Reducing pixel dimensions saves far more than lowering quality, and it costs nothing visible. Measured on one 1280 × 854 photograph with the same encoder:
| Treatment | Size | Appearance |
|---|---|---|
| Full width, quality 80 | 67.5 KB | Excellent |
| Full width, quality 40 | 20.6 KB | Visible blocking and ringing |
| Half width, quality 80 | 16.4 KB | Excellent |
Halving the width produced a smaller file than crushing the quality, and it looks like the original instead of like a bad copy. A modern phone photograph is 4000 pixels or more on the long edge. Nobody reading an email views it at 4000 pixels.
1600 pixels on the long edge is the right target. It fills a laptop screen, survives a full-screen view, and prints acceptably at postcard size. 2400 pixels is defensible when the recipient will crop or print larger. 4000 pixels is never necessary for email.
A budget per image
- Photograph for viewing
- 1600 px long edge, quality 80. Typically 100 KB to 250 KB.
- Photograph that may be printed
- 2400 px long edge, quality 85. Typically 300 KB to 600 KB.
- Screenshot
- Native dimensions, PNG. Do not resize a screenshot: text becomes unreadable. Do not save it as JPEG below quality 90 either.
- Scanned document
- 200 DPI, quality 80, greyscale where the original is monochrome. Typically 100 KB to 300 KB per page.
- Signature or logo
- Under 20 KB, PNG with transparency.
At 150 KB per photograph, 20 images occupy 3 MB of files and about 4.1 MB encoded — comfortable inside every limit above.
Send many photographs a different way
Past roughly 20 images, attachments are the wrong mechanism regardless of size. Mail clients render them inline, mailboxes fill up, and the recipient cannot download them as a set.
A ZIP archive solves the handling problem but not the size problem. Photographs are already compressed, so zipping them saves almost nothing — DEFLATE finds no repetition in JPEG data. Zip to keep a set together, not to make it smaller.
Above 25 MB, send a link. Gmail offers Drive automatically past its limit; OneDrive, Dropbox and WeTransfer all work. A link also lets the recipient download at full resolution if they need it, which an aggressively resized attachment does not.
Images inside HTML email
Images embedded in a marketing or newsletter template follow different rules from attachments, because they are downloaded when the message is opened rather than travelling with it.
Keep a header banner under 100 KB. It is the first thing requested and the most common reason an email renders slowly. Keep the total of all embedded images under 1 MB. Many clients block images until the reader allows them, so the message must make sense with every image missing — which means real text, not text baked into a picture.
Use JPEG or PNG here, not WebP. Support across email clients is inconsistent in a way it no longer is across browsers.
What not to do
Do not paste a photograph into the body of the message from a phone. Most clients embed it at full resolution and the message becomes several megabytes without showing you a file size.
Do not photograph a document with a phone camera when you can scan it. A photographed page is a large, badly lit, perspective-distorted image of text — the worst case for compression and for legibility. A scan at 200 DPI is smaller and readable.
Do not lower quality below 70 to hit a limit. The measurements above show that resizing gets you there with a better-looking result. If a file still will not fit after resizing to 1600 pixels at quality 80, resize further rather than compressing harder.
Do not send a PNG of a photograph. On the test image PNG produced 1274.1 KB against 67.5 KB for JPEG — 19 times larger for a difference nobody can see.
A workflow that repeats
- Copy the photographs into a working folder. Never edit the originals.
- Resize all of them to 1600 pixels on the long edge in one batch.
- Encode at quality 80, or set a target size per file if a strict limit applies.
- Strip metadata if the photographs were taken at home or anywhere private. Phone photographs carry GPS coordinates.
- Check the total, and multiply by 1.37 to get the size the mail server will measure.
- Attach if the encoded total is under 7 MB. Send a link if it is not.
The bulk compressor on this site handles steps two and three together, in the browser, with a ZIP download at the end. Nothing is uploaded, which matters when the photographs are personal.
Sending scanned documents
Scanned pages follow different rules from photographs, and getting them wrong produces either an unreadable file or a needlessly enormous one.
Scan text at 200 to 300 DPI. Below 200 the characters break up when the recipient zooms; above 300 the file grows without becoming more legible. A 600 DPI scan of an A4 page is fighting you before compression begins.
Scan monochrome documents in greyscale rather than colour. A greyscale scan holds one channel instead of three, and the file is roughly a third the size with no loss of legibility for black text on white paper.
Send multi-page documents as a single PDF, not as a folder of images. One attachment arrives in order, prints as a unit and cannot be partially lost. A set of twelve JPEGs named scan001 through scan012 is a burden for the recipient.
Do not resize a scan the way you would resize a photograph. The 1600-pixel rule applies to pictures, where detail is decorative. In a document, detail is the content.
Doing this on a phone
Both major mobile platforms offer resizing at the point of sending, and both hide it slightly.
On iOS, attaching photographs through the Mail app produces a size prompt when the message is sent — Small, Medium, Large or Actual Size. Medium is roughly right for viewing. The prompt appears after you press send, which is why people miss it and dispatch full-resolution originals.
On Android, Gmail attaches at full resolution by default and does not prompt. Resize before attaching, either in the gallery app's share flow or with a compression tool, then attach the reduced copy.
On both platforms, be aware of what a phone photograph actually is. A recent handset produces 12 to 50 megapixel files, frequently in HEIC rather than JPEG. HEIC is smaller than JPEG at the same quality but is not readable by every desktop mail client, so converting to JPEG on the way out avoids a support conversation.
When the recipient cannot open the file
Two formats cause most of these support conversations, and both are avoidable at the sending end.
HEIC is the default on recent iPhones. It is efficient and it is not readable by every Windows mail client or older desktop application without an additional codec. If the recipient reports that the attachment will not open, this is almost always why. Convert to JPEG before sending, or set the phone to capture in the compatible format.
WebP causes the same problem in email specifically. Browser support is universal, but email client support is not, and a WebP embedded in an HTML message may render as a broken image for a meaningful share of readers. Use JPEG or PNG in email even though you would use WebP on the web.
There is a third case worth knowing. Some corporate mail gateways strip or quarantine attachments by extension rather than by content, and a few block archive formats outright. If a ZIP disappears silently between two organisations, that is usually the cause, and a shared link is the way around it.
When a message bounces
A rejection for size arrives as a non-delivery report, often naming a limit in megabytes. Read the number: it tells you the receiving server's limit, which you had no way to know beforehand.
Do not respond by lowering quality further. Resize instead — the measurements above show it produces a smaller and better-looking result. Halving the long edge cuts the pixel count to a quarter, and file size falls close to proportionally.
If the message still will not fit after resizing to 1600 pixels at quality 80, the set is too large for email and no amount of compression will fix it honestly. Send a link. A bounced message costs more time than uploading a folder to shared storage.
Image-heavy signatures
An email signature containing a logo, a set of social icons and a certification badge attaches those images to every message you send. In a long thread they are attached repeatedly, once per reply.
Keep the total under 50 KB. Use one small PNG or SVG logo rather than five separate icon files, and link the social profiles as text. A signature that adds 300 KB per message adds several megabytes to a twenty-message thread, and it is the most common reason a mailbox fills up faster than its owner expects.
How these numbers were measured
The three-row resize comparison comes from one photograph at 1280 × 854, encoded through libvips 8.17.3 via sharp 0.34.5 with libjpeg-turbo. The half-width row was resized to 640 pixels with the default Lanczos filter before the same quality 80 encode. Sizes are exact byte lengths converted at 1024 bytes per kilobyte. The PNG comparison uses compression level 9 on the same source.
The base64 figures are arithmetic rather than measurement: base64 encodes 3 bytes as 4 characters, giving exactly 4/3, and MIME line breaks every 76 characters add approximately a further 2.7%. The combined 1.37× is rounded up deliberately, since headers and boundary markers add a little more.
Attachment limits are the published figures for the named providers and were correct at the time of writing; corporate server limits are set by administrators and vary. The per-image budget ranges are conventions drawn from the file sizes these settings produce, not measurements of a specific image set.