How to reduce photo size for email

A practical guide · Updated June 2026

You attach eight holiday photos, hit send, and the message bounces back with something like 552 message size exceeds maximum permitted. Or worse, it appears to send and never arrives. Both have the same fix, and it takes about ninety seconds once you know the two numbers to aim for: a long edge of 1600 to 2000 pixels and a file size of 200 to 500 KB per photo. Hit those and almost any set of photos becomes sendable, still looks sharp on screen, and prints fine at postcard size. Here is why the limits behave as they do, and how to get there without handing your photos to a website.

Why attachments bounce even when the maths looks fine

Email was designed to carry text, and it still is. Attachments are not sent as raw files: they are converted into plain ASCII characters using an encoding called base64, which turns every three bytes into four. Add the line breaks the standard requires and the real inflation is roughly 37%. A folder of photos that Windows Explorer reports as 20 MB arrives at the mail server as about 27.4 MB of message.

That single fact explains most mystery bounces. If your provider caps messages at 25 MB, your actual photo payload has to stay under about 18 MB, not 25. People attach 22 MB of photos, see they are "under the limit", and get rejected anyway.

The second trap is that two limits apply, and the smaller one wins. Your provider decides what you may send; the recipient's decides what it will accept. Gmail will happily send a 24 MB message to a company mailbox whose server rejects anything over 10 MB, and the failure notice can take hours to arrive or land in a folder you never check. Emailing a work address, a school, an insurer or a government office? Assume a 10 MB ceiling.

Attachment limits by provider

These are the stated per-message limits for the major consumer services as of 2026. The middle column is what is actually left for photo data after encoding overhead, and the last column is the practical answer to "how many can I attach" using a 400 KB target per photo.

Email serviceStated limit per messageReal photo payload400 KB photos that fit
Gmail25 MBabout 18 MBabout 45
Outlook.com / Microsoft 36520 MBabout 14.5 MBabout 36
Yahoo Mail25 MBabout 18 MBabout 45
iCloud Mail20 MBabout 14.5 MBabout 36
Proton Mail25 MBabout 18 MBabout 45
Typical corporate mail server10 MBabout 7 MBabout 18

Limits do change and administrators can tighten them, so treat these as the ceiling rather than the target. The number worth memorising is the bottom row: keep the total under 7 MB of actual files and the message goes through essentially everywhere.

The recipe: resize first, then compress

Order matters, and most people get it backwards. Halving the long edge quarters the pixel count, so resizing alone typically strips 70 to 75% of the bytes before compression touches anything. Compression then trims the remainder to your kilobyte budget. Do it the other way round and you agonise over detail you are about to throw away.

  1. Resize the long edge to 2000 pixels. Whether the photo is portrait or landscape, you constrain whichever side is longer. A 4032 × 3024 phone photo becomes 2000 × 1500 — a quarter of the pixels, and the single biggest saving you will make.
  2. Save as JPG at 75–85% quality. Eighty is the reliable default for photographs. Below about 70 you start seeing blocky patches in skies and smooth skin tones.
  3. Check the result is 200–500 KB. Busy scenes with foliage or crowds land at the top of that range; a portrait against a plain wall can come in under 150 KB. If a photo is still over 800 KB, drop quality to 70 rather than shrinking the dimensions further.

Use 1600 pixels instead of 2000 when you have a lot of photos or you know the recipient is on a slow connection. Use 2400 only when the recipient has specifically said they want to print at A4 or larger — and at that point a link is usually the better answer.

One format note: send JPG, not WebP. WebP is smaller and it is the right choice for a website, but plenty of desktop email clients and older phones still refuse to preview it inline, and a photo that arrives as a grey box is worse than one that is 40 KB bigger. Our guide to compressing images for the web covers where WebP is the right call.

Worked example: 10 phone photos, 45 MB, one email

Here is the situation almost everyone actually has. Ten photos straight off a recent phone, 4032 × 3024 pixels, averaging 4.5 MB each. Total on disk: 45 MB. Encoded for email that becomes about 61.6 MB, so it fails on every service in the table — not marginally, but by a factor of two and a half.

Now run the recipe. Resize the long edge to 2000 pixels: each photo drops from 12.2 megapixels to 3.0 megapixels, roughly a quarter of the data. Export as JPG at quality 80. The typical result is 380 to 420 KB per photo, so call it 400 KB.

That clears the 10 MB corporate ceiling with room to spare, downloads instantly on the other end, and each photo still opens at 2000 pixels wide — bigger than the screen most recipients will view it on. You could add another eight photos and stay under 10 MB.

Compare that with the two shortcuts people usually reach for. Zipping the 45 MB of originals gives you roughly 44 MB, because JPGs are already compressed. Emailing them one at a time means five separate messages and five chances for one to bounce. Ninety seconds of resizing beats both.

When you have 30 photos, not 10

Past about 15 photos, stop optimising and change strategy. Even at 400 KB each, 30 photos is 12 MB of files and 16.4 MB of message: over the limit at Outlook and iCloud, and far over it at any workplace. Your realistic options:

A hybrid works well: attach the best three or four at 400 KB so the recipient sees something immediately, and put the full set behind a link underneath. Most people never open the link, which tells you something about how many photos anyone actually wants.

Keeping enough quality to print

The usual worry about shrinking photos is that grandma will want a print and you have ruined it. The arithmetic is reassuring. Print sharpness is measured in pixels per inch, and 300 PPI is the traditional standard for photographic quality, though 240 PPI is genuinely hard to distinguish at normal viewing distance.

Long edge sent4 × 6 print5 × 7 print8 × 10 print
1200 px200 PPI — acceptable171 PPI — soft120 PPI — no
1600 px267 PPI — good229 PPI — acceptable160 PPI — no
2000 px333 PPI — excellent286 PPI — good200 PPI — soft
3000 px500 PPI — excellent429 PPI — excellent300 PPI — excellent

So a 2000 pixel long edge comfortably covers the two print sizes ordinary people actually order. It only falls short at 8 × 10 and larger, and anyone framing an enlargement should get the untouched original by link — not a JPG re-saved twice. Keep your originals and email a copy: the one unrecoverable mistake here is overwriting a 4.5 MB original with a 400 KB version.

Two things that quietly ruin emailed photos

HEIC files. iPhones shoot in HEIC by default. Sent to another iPhone this is invisible; sent to a Windows PC or an Android phone the recipient often gets a file that will not open at all. Converting to JPG on the way out solves it permanently — see converting HEIC to JPG. If you would rather fix it at the source, set Camera to "Most Compatible" in your iPhone settings.

Hidden location data. Every phone photo carries EXIF metadata: the exact GPS coordinates, the timestamp, the device serial. Email a photo of your living room to a stranger on a marketplace listing and you have emailed them your home address. Most resizing tools drop this data as a side effect of re-encoding, which is a happy accident rather than a guarantee — if it matters, strip metadata deliberately before sending.

Doing it without uploading anything

Most "reduce photo size for email" sites ask you to upload your private photos to their server first. Medical documents, ID scans for a landlord, a damaged parcel for an insurance claim — the files people most need to shrink are the ones they least want on somebody else's hard drive.

That is avoidable. Modern browsers can decode, resize and re-encode images on your own machine using the HTML canvas API: the work happens in the tab and the result goes straight to your Downloads folder. Nothing crosses the network — no upload wait, no server-side copy, no retention policy to read, and it works on a plane with the wifi off. It is faster, too: uploading 45 MB takes a minute or two before any work starts, while locally it finishes in seconds.

Frequently asked questions

How do I reduce photo size for email without losing quality?

Resize before you compress. Set the long edge to 2000 pixels, which is still enough for a sharp 6-inch print, then save as JPG at 80% quality. A 4.5 MB phone photo lands between 300 and 500 KB, and on a screen the recipient cannot tell the difference. The detail you give up is detail nobody was going to see, because almost no email client displays a photo wider than about 1000 pixels anyway.

How many photos can I attach to one email?

With Gmail's 25 MB message limit, about 45 photos at 400 KB each, because base64 encoding inflates attachments by roughly 37% in transit. On a 20 MB service such as Outlook or iCloud Mail it is about 36. In practice stop at 15 or 20, since the recipient's mail server enforces its own limit too and plenty of company servers reject anything over 10 MB.

Is it better to zip photos or send a cloud link?

Send a link once you are past about 15 photos. Zipping barely helps, because JPG and HEIC files are already compressed, so an archive of photos usually saves only 1 to 3% and it still counts against the same attachment limit. A shared folder link keeps the message tiny, survives strict corporate filters that quarantine zip files, and lets the recipient pull the full-resolution originals if they want to print them.

Try the free tool — in your browser, nothing uploaded

Two steps, no account, no watermark. Do them in this order:

If you want a rough sanity check before you start: multiply your photo count by 0.4 MB, then by 1.4 for encoding. If the answer is under 10, hit send.