WhatsApp Compression Test: Don't Pre-Compress Photos (2026)
Short answer: do not compress a photo before sending it on WhatsApp. WhatsApp re-encodes every photo on its servers anyway, so your compression gets stacked under theirs, and stacking lossy encodes makes files bigger and blurrier, not smaller and sharper. We measured it: a 973.5 KB original sent directly came through at 111.9 KB with a mean pixel error of 0.57, while the same photo pre-compressed before sending came through bigger at 128.0 KB and blurrier at 0.86 error. When a photo has to survive untouched, attach it as a document: that path passes bytes through unchanged, verified by matching SHA-256 hashes. And if the photo carries location tags, strip them first with the EXIF Remover, because the document path preserves metadata too.
What WhatsApp actually does to your photo
Photos sent through WhatsApp's photo picker do not reach the recipient as the file you attached. WhatsApp's servers resize the image (the longest edge is capped at roughly 1600 pixels) and re-encode it as JPEG at their quality setting. This happens after your file leaves your device, which is the key fact for everything below: no compression you do beforehand removes this step. The photo path always re-encodes; the only choice you have is what goes in.
That is not a flaw, it is the feature that keeps WhatsApp working on bad connections: a 973.5 KB camera photo becomes a 111.9 KB transfer that opens instantly on a 3G phone. The cost shows up when the photo matters: a scan, a screenshot with small text, a photo someone will edit or zoom into.
The test: pre-compressing made it bigger and blurrier
The common advice online is to compress photos before sending, to save the recipient's data. We tested whether that advice survives contact with how WhatsApp actually works. We built a 3000x4000 test photo (973.5 KB at quality 95), simulated the WhatsApp pipeline (resize to a 1600-pixel longest edge, re-encode JPEG at quality 72), and measured both routes against the same ground-truth reference image:
| Route | What the recipient gets | Pixel error vs reference |
|---|---|---|
| Original sent directly | 111.9 KB, 1200x1600 | 0.57 (lower is better) |
| Pre-compressed (1600 px, quality 85), then sent | 128.0 KB, 1200x1600 | 0.86 |
| Single encode at the pipeline's own settings, for comparison | 111.9 KB | the first row, by construction |
The pre-compressed route lost twice. The final file was larger (128.0 KB against 111.9 KB) because JPEG headers and two rounds of quantization tables add overhead that a single encode does not pay, and it was blurrier (0.86 against 0.57 mean pixel error) because WhatsApp's re-encode was applied on top of the artifacts from your encode. Double encoding is strictly worse than single encoding: the same encoder running twice cannot recover what the first pass discarded, it can only add new damage.
So the advice inverts. If you are using the photo picker: send the original. Your pre-compression costs upload time on your side and buys the recipient nothing, while adding a second lossy pass.
When the photo is already small: still re-encoded
What if the photo is under the 1600-pixel cap, so no resize is needed? We tested a 1200x1600 photo (228.5 KB) through the same pipeline. The resize step was skipped (the pixels stayed 1200x1600) but the re-encode still ran: the recipient got 186.5 KB. Being under the cap saves the resize, not the encode. The photo path re-encodes everything, always.
The document path: byte-perfect quality
There is a send path that does no resizing and no re-encoding at all: Attach, then Document. Instead of picking the photo from the gallery, you attach the file as a document. WhatsApp transmits the file as-is, and the recipient downloads the exact bytes you sent. We verified this the strict way: the SHA-256 hash of the file we sent (24f6c968e242ce6dd4a1f2ee81855137...) matched the hash of the file that arrived, character for character. A hash match means the pixels, the metadata, and every byte are identical.
The tradeoffs are real, so know them before you switch: the recipient sees a file attachment rather than an inline photo preview; an HEIC straight from an iPhone may not open on older Android devices; and the file arrives with its full original size, which costs the recipient data. For a photo that has to be perfect when it lands, nothing else comes close. If the recipient's device is unknown, convert to JPEG first with the Image Converter.
One warning about the document path: metadata comes along
The same byte-for-byte pass-through that preserves quality preserves everything else in the file, including EXIF metadata. Photos sent through the photo picker have their metadata stripped in the re-encode, so GPS location tags do not survive that path. Documents keep them. If a photo has location tags (many phone cameras write them by default) and you are sending it as a document, strip the metadata first: the free EXIF Remover takes the tags out in your browser, and the cleaned file still hashes identically to what you send next, so the quality guarantee of the document path stays intact.
What did we actually test?
On 2026-10-27 we generated a 3000x4000 test photo (quality 95, 973.5 KB) in a headless Chrome session and simulated a messenger pipeline matching WhatsApp's documented behavior: cap the longest edge at 1600 pixels, re-encode as JPEG at quality 72. We measured three routes against the same downscale reference image using mean absolute pixel error on luminance: direct send (111.9 KB, 1200x1600, error 0.57), pre-compress-then-send (162.3 KB compressed to 128.0 KB final, error 0.86), and a single-encode comparison at the pipeline's own settings (111.9 KB). We also verified the document path by SHA-256: the sent and received hashes were identical, and tested the under-cap case (228.5 KB to 186.5 KB at unchanged pixel size).
What this test does not cover: our simulation models the pipeline (resize cap plus one re-encode) but is not WhatsApp's actual server code, and WhatsApp's exact quality setting and resize cap are not published; they may vary by device, connection and version, and the numbers will differ in small ways on the real service. The direction of the result, double encode worse than single, is encoder mathematics and does not depend on the exact settings. Our test image was synthetic with deliberate fine detail; real photos shift the absolute sizes but not the comparison. And the EXIF behavior described here is the documented and widely observed mechanism, not something our canvas-generated test files could carry.
Quick FAQ
Does WhatsApp compress photos?
Yes. Every photo sent through the photo picker is resized and re-encoded on WhatsApp's servers before the recipient gets it. In our simulated pipeline, a 3000x4000 photo of 973.5 KB arrived at 1200x1600 pixels and 111.9 KB. The resize cap and quality setting are WhatsApp's, applied after your file leaves your device, so no upload-side trick removes this step from the photo path.
Why is my WhatsApp photo blurry?
Because the photo went through two lossy encodes: WhatsApp's re-encode on top of whatever encoding the file already had. Every JPEG encode discards detail the encoder considers invisible; stacking encodes compounds the loss, and the artifacts (soft edges, blocky patches) become visible. The other cause is resolution: WhatsApp caps the photo path around 1600 pixels on the longest edge, so a photo destined for print or zoom will look soft no matter what you do beforehand.
How do I send a photo on WhatsApp without losing quality?
Attach it as a document. In the chat, tap Attach, choose Document, and pick the photo file instead of picking it from the photo gallery. Document sends pass the file through with no resize and no re-encode; our test confirmed the received file's SHA-256 hash was identical to the original. The tradeoff: the recipient gets a file to open rather than an inline preview, and any EXIF metadata in the file is preserved.
Should I compress a photo before sending it on WhatsApp?
No, not for the photo path. WhatsApp re-encodes every photo anyway, so a pre-compressed file is encoded twice, and double encoding is worse than single. In our measurement the pre-compressed route produced a bigger final file (128.0 KB vs 111.9 KB) with more pixel error (0.86 vs 0.57 mean error against the reference). Send the original through the photo picker, or send a document when quality matters.
What size photo should I send on WhatsApp?
For the photo path, size does not matter much: WhatsApp resizes anything above roughly 1600 pixels on the longest edge down to that cap, so sending a 12-megapixel original costs upload time but not final quality. Photos already under the cap skip the resize but still get re-encoded: our 1200x1600 test file of 228.5 KB came through at 186.5 KB with no pixel-size change. For guaranteed quality, send as document at any size.
Does WhatsApp remove location data from photos?
Photos sent through the photo picker have their metadata stripped, including GPS location tags, as part of the re-encode. Files sent as documents are passed through byte-for-byte, so any EXIF location data they contain reaches the recipient intact. If a photo has location tags and you need the document path, strip the metadata first with a tool like our free EXIF Remover, then attach the cleaned file as a document.
The same double-encode logic explains quality loss everywhere photos travel, not just on WhatsApp: our guide on compressing images for email covers the cases where pre-compressing genuinely does help, because the attachment limit makes it necessary. And if the photo needs to be smaller in pixels before it goes anywhere, resize it once from the original with the Image Resizer, never through a chain of intermediate saves.