A full-screen capture on a Retina Mac can land anywhere from a couple of megabytes to well over ten. That is fine on your disk and a problem the moment you attach it to an email. The reason is the format: macOS saves screenshots as PNG, which is lossless, and lossless means it never throws away detail to make the file smaller.
Email providers cap attachments, and the caps are lower than most people assume:
| Provider | Send limit |
|---|---|
| Gmail (personal) | 25 MB for all attachments combined |
| Outlook.com | 20 MB |
| iCloud Mail | 20 MB, then it offers Mail Drop |
| Corporate Exchange | Commonly 10 MB, set by your admin |
One detail worth knowing: email encodes attachments as text, which inflates them by roughly a third in transit. A 19 MB file can arrive as a 26 MB message and bounce. Practical ceiling is closer to 15 MB than to the advertised number.
The cheapest fix is to crop
Before changing format or dimensions, ask whether you need the whole frame. Every pixel you remove is a pixel you no longer pay to encode, and you keep full quality on what remains. Cropping a screenshot down to the relevant panel typically halves the file with no loss whatsoever.
Crop in the editor before you export. If you have to do it afterwards in Preview, select the area, then ⌘K.
Resizing without losing real detail
If cropping isn’t enough, halving the dimensions is the next step. Preview handles it: Tools → Adjust Size, set the width, and make sure Resample Image is checked. Without that checkbox, Preview only changes the resolution metadata and the pixel count stays the same, so the file does not shrink.
To check what you are working with before you resize, open Tools → Image Information in Preview, which reports the current dimensions.
Resizing is not free, though. A 3200px-wide capture resized to 1600px is a new image with new pixels. Nothing can restore what resampling removed, so keep the original.
The part people get wrong about JPEG
The instinct is “switch to JPEG, it’s always smaller.” For screenshots that is often false, and it is worth knowing why.
PNG compresses by finding repeated patterns. A user interface is mostly flat color, identical icons, and repeated whitespace, which is exactly what PNG handles well. A photograph or a dense gradient is the opposite, and JPEG’s approach suits it.
The same JPEG quality setting can produce opposite results depending on content:
| Capture type | JPEG at high quality compared with PNG |
|---|---|
| Dense UI or code editor | Often larger |
| Photo-like or gradient-heavy | Usually much smaller |
So for a UI screenshot, going to JPEG can make the file bigger. For a chart or a photo inside a report, it can shrink it by an order of magnitude.
The other cost is text. JPEG is lossy, and its artifacts show up first around sharp high-contrast edges, which in a screenshot means small text. At quality 80 to 90 it is hard to see; below 70 it gets noticeably soft.
What to reach for
- UI, code, or anything with small text: stay PNG, crop, and resize. Lossless keeps the labels crisp.
- Photo-like content, charts, gradients: JPEG at 80 to 90, or HEIC if the recipient is on Apple hardware and you can accept the format is not universal.
- Sending by email at all: a link beats an attachment, because it sidesteps the size cap entirely. Free links expire after 7 days; Pro links can remain live for up to 90 days (90 days by default).
A quick order of operations
- Crop to the part that matters. Free win, no quality loss.
- Check the size. If it comfortably fits, stop here.
- Resize a copy to about half width if it is still too big.
- Re-encode only if the content suits it: JPEG for imagery, PNG for interfaces.
- Otherwise send a link and let the file live on someone else’s server.
Keep the original capture regardless. Resizing and re-encoding are lossy in ways that are easy to forget, and redoing a screenshot means doing the work again.