Does Gmail Compress Images? Attach vs Inline, Measured

No for attachments, yes for inline. Does Gmail compress images? On 2026-07-18 I attached a 4.13 MB iPhone photo to a Gmail message and it arrived byte for byte identical, same sha256 checksum. The same photo inserted inline into the message body came back 55.1 percent smaller, re-encoded from 4.13 MB to 1.86 MB. Where you drop the file decides what Gmail does to it.

Scope, stated plainly: each number is what Gmail did to one reference file, on one day, through one named path. I measured the attach path and the inline path from the compose window. I did not separately measure dragging versus pasting versus the Insert Photo button, and I did not measure the phone apps. Everything below keeps my measurements separate from what Google documents and from what third parties report.

Does Gmail Compress Images? What My Test Measured

Attachments, no. Inline, yes. Both halves of that answer come from the same two files sent through both paths on the same day, then compared on disk against the originals at the byte level.

The two reference files

Every platform in this series meets the same reference files, so results line up across pages. REF-A is a real iPhone photo: 4,332,705 bytes, 4032x3024 pixels, JPEG, carrying the full EXIF block a phone camera writes, meaning the hidden metadata with camera model, timestamp, and GPS coordinates. REF-B is a photographic cutout with real transparency: 1,863,465 bytes, 1240x930, PNG with an alpha channel. The full roster of results lives on the hub covering which apps compress your images.

Attached photos survived to the checksum

I attached both files with the paperclip, sent them, downloaded the delivered copies, and hashed everything. Same sizes. Same dimensions. Same sha256 fingerprints. A matching sha256 means the delivered file is the same file, bit for bit; there is no such thing as gentle compression that keeps the checksum. On the attach path, Gmail moved my photos the way a file server moves a zip archive, untouched.

Inline copies did not

The same iPhone photo dropped into the message body arrived as a 1.86 MB JPEG, 55.1 percent lighter than the file I inserted. The PNG shed 17.7 percent and landed at 1.46 MB. Neither lost a single pixel of dimensions: the JPEG kept 4032x3024 and the PNG kept 1240x930. Lighter files at identical dimensions is the signature of re-encoding, not resizing.

What this proves and what it does not

It proves the attach path applied no compression at all in my test, and that the inline path measurably re-encoded both files. It does not prove that every inline route behaves identically, it says nothing about the Android or iOS apps, and it is one day, one account, two files. A dated data point beats folklore, and folklore is most of what this question had.

Does Gmail Compress Photos Inserted Inline?

Yes, measurably. Inline insertion cost my JPEG more than half its bytes and my PNG nearly a fifth, while the pixel dimensions of both survived unchanged. Here are the four results side by side, then what they overturn.

The 1,280 pixel folklore did not survive the test

Tutorials and forum answers have repeated for years that Gmail resizes inline images to roughly 1,280 pixels on the long side. My inline JPEG came back at its full 4032x3024. On the path I measured, Gmail did not downscale anything; it recompressed. Byte loss without pixel loss also explains why the folklore persists: the picture looks about the same in the message, so people guess at the mechanism instead of hashing the files.

Original Size, Small, and Best Fit set layout, not bytes

Click an inline image in the compose window and Gmail offers Small, Best Fit, and Original Size. In an official help thread, a Google product expert states that inserting an image inline does not alter the quality of the file. My measured copy left 55.1 percent of its bytes behind, so on my path, that answer did not hold. I do not think anyone is lying; I think display width and stored bytes get conflated constantly in this argument. Community consensus is that those three buttons control how wide the picture renders in the message layout. Nothing about them promises the transmitted file is your original, and my test says it was not.

If you want the inline look, feed it a file you chose

An inline photo is a rendering decision, and you can make it on your own terms. Compress the photo on your own terms at a quality you picked before inserting it, and Gmail's pipeline has nothing dramatic left to do. A file you already sized sensibly arrives looking the way you approved it, preview and all.

Why Does Gmail Recompress Inline Images but Not Attachments?

Because they are two different machines. An attachment is cargo: email protocols carry it as an encoded block and reassemble it unchanged at the far end. An inline image becomes part of a web page that Gmail has to render quickly inside an inbox, and rendering pipelines optimize whatever they touch.

Attachments ride the protocol

When you attach a file, Gmail wraps it in a MIME part, the standard container email has used for decades, encodes it for transport, and ships it. The receiving side decodes it back to the original bytes. No image processing happens at any point, which is why my hashes matched and why this is not really Gmail being generous. It is email doing what email was designed to do: deliver files intact.

Inline images join the page

Drop that same photo into the message body and it stops being cargo. Gmail embeds it as part of the message's HTML, and the copy it stores for that job is Gmail's to prepare. My measurement says the preparation includes a heavy JPEG re-encode. Gmail has also routed images in opened mail through its own proxy servers since 2013, for caching and security, so the version a recipient sees on screen has passed through more Google machinery than an attachment ever does.

Every JPEG re-encode spends quality you cannot get back

JPEG is a lossy format: each re-encode discards detail permanently, and the generations stack. A photo that goes inline through Gmail, gets saved by the recipient, and goes inline again is two generations down before anyone notices. The full mechanics live in the guide on lossy versus lossless compression. So does Gmail compress images out of malice? No. It optimizes what it renders and leaves alone what it merely carries.

What Is the Gmail Attachment Size Limit?

25 MB to send and 50 MB to receive on a personal account, and the ceiling is a swap trigger, not a compressor. As Gmail's own help page on attachments documents, a file over the limit is uploaded to Google Drive and replaced with a link; Gmail never squeezes an oversized attachment down for you.

The compression behavior I measured is a pipeline question, not an account question; nothing suggests a Workspace mailbox re-encodes attachments any differently. What changes by tier is only the ceiling, and only Enterprise Plus has moved off the 25 MB default so far.

The limit is measured on the wire, not on your disk

Email attachments travel Base64 encoded, and the Base64 specification maps every 3 bytes of file to 4 characters of text, inflating each attachment by roughly a third in transit. A 24 MB photo therefore weighs about 32 MB on the wire and bounces off the 25 MB ceiling even though your disk says it fits. The practical budget is about 18 MB of files per message. My 4.13 MB reference photo occupies roughly 5.5 MB encoded, so four photos that size fill an allowance.

Over the limit, Gmail reaches for Drive

The Drive handoff is the quality-preserving overflow valve. Nothing is recompressed on that route either: in my separate test, Google Drive returned the same photo byte for byte identical, same sha256. For a large batch of full-size photos, sharing a Drive link on purpose beats hitting the ceiling by accident, and the recipient downloads originals instead of a bloated inbox.

Does Gmail Strip EXIF Metadata From Photos?

Not from attachments, and my test proves it the strong way: the delivered copies matched the originals to the checksum, and identical bytes mean the entire EXIF block survived, camera model, timestamp, and the GPS coordinates of where I stood when I took the picture. A peer-reviewed forensic study of email attachments found the same with hash verification: email is one of the only common transfer paths that preserves metadata completely.

A feature for archiving, a trap for privacy

For moving originals, perfect. For privacy, be deliberate: Gmail will not scrub your location for you, unlike the social platforms that strip EXIF as a byproduct of re-encoding everything. If a photo should not carry GPS to a stranger, strip the metadata before attaching it. Our compressor removes EXIF by default for exactly this reason, no setting to hunt for.

The inline copy is a question mark

I did not verify what the inline re-encode does to metadata, so this page will not claim it. The attached copy provably keeps everything. If EXIF matters to you in either direction, keeping it or killing it, the attach path is the one with a measured answer, and the stripping is your job before the file ever reaches Gmail.

How to Send Photos in Gmail Without Compression

Use the paperclip and stay under the ceiling. That is the whole trick, and my checksums back it. Here is the exact flow, plus the fork that quietly catches people.

The steps that keep every byte

1. Click Attach files, the paperclip icon, in the compose window, and pick your photos.
2. If you drag files instead, drop them on the attachment bar at the bottom of the compose window, never into the text area. The drop zone decides the path: the body means inline, and inline means re-encoding.
3. Confirm each photo appears as a file chip under the message, not as a picture inside it.
4. Send. In my test the delivered file matched the original sha256 exactly.

If you want a belt with those suspenders, zip the photos first. A zip does not meaningfully shrink JPEGs, they are already compressed, but an archive can never be mistaken for an inline image, so it is guaranteed to ride the attachment path intact.

On a phone, the honest answer is messier

My measurements came from the desktop web compose, and I have not measured the mobile apps. What is documented: Android users report that the old resize prompt no longer appears when sharing photos through the Gmail app, and iOS behavior shifts depending on whether photos come from the camera roll or Google Photos. Until I run the phone tests, treat mobile sends as unverified and use the web compose with the paperclip when the bytes matter.

When the photo has to be smaller anyway

The ceiling arrives fast: at 4 MB per phone photo plus encoding overhead, a message holds about four before Gmail reaches for Drive. When you need ten photos in one email, compression you control beats a swap you did not plan. The full workflow, format choice, quality level, and the caps other providers enforce, lives in the guide on compressing images for email.

How Does Gmail Compare to Outlook and the Other Apps I Tested?

On attachments, Gmail sits in the small club of services that measurably do not touch your file. On inline handling, the two big mail clients split in a way worth seeing side by side.

Both mail clients delivered attached files byte for byte identical, which suggests attachment integrity is an email-protocol property, not a brand feature. Inline is where they diverge: Outlook downscaled the same photo to 1920x1440 and stripped its EXIF, while Gmail kept every pixel and quietly re-encoded. The cluster-wide pattern holds across categories too: WhatsApp's document path returned the identical file exactly the way the email attach paths did. When a service treats your photo as a file, it survives. When a service treats it as media to display, it gets processed.

Attach It, or Send a File You Already Approved

So, does Gmail compress images? Attach and it provably does not, my photos came back checksum-identical. Insert inline and on my measured path it re-encoded more than half the bytes away. The control is entirely yours, and it costs one habit: use the paperclip when the original matters.

When the file needs to be smaller before it goes anywhere, size it yourself with the photo compressor first: quality 80 by default, up to 30 images at a time at 25 MB each, EXIF stripped by default so an emailed photo does not carry your GPS trail, and uploads deleted within the hour. For the wider playbook on getting images under every provider's ceiling, start with the guide on compressing images for uploads.