You've just taken the perfect photo and want to send it on WhatsApp — but the file is 4 MB, and it arrives blurry on the other end because WhatsApp recompresses it automatically. Or worse, it doesn't send at all because your internet is slow.
The solution is simple: compress the image before sending it. This guide explains exactly how to do that in seconds, directly in your browser — no app download, no sign-up, no image uploaded to any server.
WhatsApp automatically reduces image quality when you share photos. It does this to save mobile data and speed up delivery. The problem? It applies aggressive compression that can make images look noticeably blurry or pixelated — especially on larger screens.
By compressing your image to a reasonable size first, you give WhatsApp less to compress, so the final result looks much sharper to the recipient.
There are two types of image compression:
For WhatsApp, a lossy compression at 60–75% quality is ideal. It reduces a 4 MB photo to under 400 KB — 10× smaller — while keeping the image visually perfect on mobile screens.
60% quality — perfect for chat and stories. Crisp on mobile.
75% quality — sharp and under 200 KB. Works in any inbox.
85% quality — fast-loading web images that look professional.
95% quality — for archiving or printing. Minimal size savings.
Browser-based, no sign-up, no data uploaded. Compress JPG, PNG, and WebP in seconds.
Compress My Images →Here's what typical real-world compression looks like with a 60% quality setting:
The images look identical on a phone screen. The difference only becomes visible if you zoom in at 400%.
No. The Apps2Help compressor runs entirely in your browser using the HTML5 Canvas API. Your photos never leave your device. There is no server-side processing, no storage, and no account needed. You can even use it offline after the page loads.
Photo compression is not one process but three, and understanding which one is doing the work tells you which setting to reach for.
Resolution is the blunt instrument. A 4000 by 3000 photo holds twelve million pixels. Halving both dimensions to 2000 by 1500 leaves three million, a quarter of the data, before any compression is applied. This is almost always the first thing to change, because almost nobody views photos at full sensor resolution.
Quantisation is the JPEG quality dial. The encoder splits the image into 8 by 8 blocks, converts each to frequency components, and then throws away precision in the high-frequency components your eye is least sensitive to. Lower quality means coarser rounding and smaller files.
Chroma subsampling exploits the fact that human vision resolves brightness far better than colour. Storing colour information at half resolution horizontally and vertically, known as 4:2:0, removes a large chunk of data with very little visible cost on photographs. It is a poor idea for screenshots containing coloured text, where it produces fringing.
| Use | Sensible long edge | Quality | Rough result |
|---|---|---|---|
| Email or messaging | 1600 px | 0.80 | 200–400 KB |
| Website body image | 1200 px | 0.80 | 120–250 KB |
| Full-width hero banner | 1920 px | 0.75 | 250–500 KB |
| Online form with a 1 MB cap | 1200 px | 0.75 | Well under the cap |
| Print at A4 | 2480 px | 0.92 | 1.5–3 MB |
| Archive copy | Original | Keep original | Unchanged |
The most common error is compressing hard while leaving the resolution untouched. A 4000-pixel-wide image at quality 0.5 looks worse than a 1600-pixel-wide image at quality 0.85, and the second one is usually smaller. Reduce dimensions first, then adjust quality.
Take a 4032 by 3024 phone photo at 4.1 MB that has to fit under 500 KB for a school portal upload.
Two adjustments, one re-encode, and the picture still looks entirely normal on any screen the portal will ever display it on.
JPEG remains the safe default for photographs and opens everywhere. PNG is lossless and right for screenshots, logos, line art and anything needing transparency, but it is a poor choice for photographs where it will often be larger than the original JPEG. WebP typically beats JPEG by twenty to thirty per cent at matched quality and is supported by every current browser, which makes it a strong choice for websites, though some desktop applications and older email clients still stumble on it.
Screenshots are full of sharp, high-contrast edges, which is precisely what JPEG handles worst. Text picks up a grey halo. Use PNG, or WebP in lossless mode.
"Under 100 KB" is fine for a thumbnail and destructive for a document scan that someone has to read. Ask what the image is for before you decide how small it should be.
Small text in a scan is exactly the fine detail that quantisation destroys. Keep scans at higher quality and higher resolution than you would a holiday snap, and check the smallest text is still readable before you send it.
Compression is one-way. There is no process that restores detail once it has been discarded, regardless of what an application promises. Keep originals somewhere before you batch-process.
It cannot sharpen a soft image, rescue an overexposed sky, or make a low-resolution photo suitable for large-format print. It cannot meaningfully shrink an image that is already heavily compressed, and trying will simply add artefacts on top of existing ones. And it cannot remove metadata unless the tool explicitly strips it, so a compressed photo may still carry GPS coordinates.
Decoding, resizing and re-encoding all happen on a canvas inside the page. The image is never transmitted. Open developer tools, watch the Network panel while you compress, and you will see nothing leave. Or disconnect from the internet after the page has loaded and compress anyway.
That matters for the things people most often need to shrink: passport scans, address proofs, medical documents, signed contracts and photographs of children for school portals. Those are precisely the files that should not be sitting on someone else's temporary storage.
Around 0.80 to 0.85 for general sharing, and 0.90 or above when the image will be printed or contains small text. Below 0.70 you will start to see blocky artefacts around edges.
Resize first. Reducing the pixel dimensions to what the destination actually displays removes far more data with far less visible cost than aggressive quality reduction.
No. Lossy compression discards information permanently. Always keep the originals somewhere before compressing a batch.
JPEG is designed for photographs and handles sharp high-contrast edges poorly. Use PNG or lossless WebP for screenshots and anything containing text.
At the same visible quality, WebP files are usually twenty to thirty per cent smaller. Every current browser supports it, but some older desktop applications and email clients do not, so JPEG is still the safer choice for attachments.
Not automatically. Metadata is only stripped if the tool deliberately does it, so check a sample if you are concerned about location data in photos you plan to publish.
Yes, and processing several at once is normally faster than doing them individually since the page reuses the same encoding pipeline.
No. Everything happens inside the browser tab. You can confirm this in the Network panel of developer tools, or by disconnecting from the internet before compressing.