How to Compress Images Without Losing Quality: Resize First, Then Encode

Three things decide how many bytes a photo takes up, and the quality setting you usually reach for first is only one of them. Pixel dimensions dominate everything else. A modern phone camera captures around 4000x3000 pixels, twelve million individual colour samples before anyone has touched the file. That is why a fresh photo weighs several megabytes straight off the device, even of something as boring as a desk.

Format is the second factor. The same scene saved as PNG can be many times the size of the same scene saved as JPEG, because PNG preserves every pixel exactly while JPEG throws away detail that human vision is poor at detecting. Embedded metadata is the third, and the one people forget. Camera files carry EXIF fields, a preview thumbnail, colour profiles and sometimes GPS coordinates. That is tens or hundreds of kilobytes rather than megabytes, but across a batch it adds up, and stripping it costs nothing visually.

Order of operations beats tuning. Take that 4000px-wide phone photo and downsize it to 1600px wide, which is generous for a full-width web image on a large desktop monitor, and you have discarded about 84% of the pixels. Pixel count scales with area, not width, so the saving is far bigger than the ratio of the two numbers suggests. If you want to reduce image file size dramatically, this is where the win comes from.

Re-encoding the original 4000px file at quality 80 will save you something, but the encoder is still labouring over twelve million pixels that no browser will ever display. Resize first and the compressor has far less to do, so you can leave quality high and still land a small file. Match dimensions to where the image actually appears: 1600px for a full-bleed hero, 800px for a half-width column, 400px or less for a thumbnail. Serving a 1600px file into a 300px slot is the most common waste on the web.

Lossy compression, which is what JPEG and lossy WebP do, permanently discards information the encoder judges you will not miss. It works in frequency space rather than pixel space, so smooth gradients and soft backgrounds survive almost untouched while fine texture gets simplified. The savings are large. Lossless compression, which is what PNG and lossless WebP do, keeps every pixel bit-for-bit and reconstructs the original exactly on decode. It works by finding redundancy, so how much it saves depends on the content, and on a busy photograph the answer is often not much.

Photos tolerate lossy well because they are already full of sensor noise and gradual transitions, so a sensible lossy pass on a photograph is close to invisible. Flat graphics are the opposite case. Logos, charts, screenshots containing text and UI mockups have hard edges and wide areas of identical colour, and lossy encoding turns those edges into faint ringing and smearing. Use lossless there even though the file stays bigger, because a fuzzy logo is a worse outcome than a heavy one.

WebP typically lands 25 to 35% smaller than a comparable JPEG at similar perceived quality, and it supports transparency, which JPEG never could. Every major browser has supported it for years, so for ordinary web delivery there is little reason to hesitate.

AVIF goes further and often beats WebP on photographs, but support is narrower and encoding is noticeably slower, so it suits situations where you control delivery and can fall back gracefully. For anything that has to open reliably anywhere, including email clients, older CMS pipelines and design software, JPEG remains the safest bet. The practical pattern is to serve AVIF or WebP with a JPEG fallback, and to keep JPEG as your archive copy.

A typical 2MB photo, resized to sane web dimensions and re-encoded, usually drops to a couple hundred kilobytes. Most of that gain comes from the resize step rather than from grinding the quality setting down until the image falls apart.

Where the compression happens matters too. A browser-based tool reads the file from your disk, does the work inside the tab and hands you a download. Nothing is uploaded, so no server-side copy of an ID document, a client's unreleased product shot or a personal photo ends up in someone else's temporary storage. For a meme that distinction is trivia. For anything with a face, a name or a contract attached to it, it is the whole point.