Three levers, three different problems
An image file carries three independent properties: its pixel dimensions (1200 × 800), its encoding format (JPEG, PNG, WebP) and its encoder quality (how much detail the format is allowed to discard). Resizing changes the first, converting changes the second, and the quality slider changes the third. A file can be shrunk by any of them, and the right choice depends on which property is actually wrong for the destination.
A 4000-pixel-wide photo displayed at 800 pixels is wasting three quarters of its pixels no matter how well it is compressed; downscaling it is the single largest saving available. A screenshot that is already the right size but saved as a 4 MB PNG needs a format change, not a resize. A photo that is the right size and format but still too large for a form's limit needs the quality lever. Applying the wrong one either does nothing for the byte count or throws away visible detail for no reason.
Lossy and lossless, in one paragraph each
JPEG is lossy: it splits the image into 8 × 8 blocks, converts each to a brightness/chroma representation, and discards the high-frequency detail the eye notices least. The blocks are why a heavily compressed JPEG shows 8-pixel squares around edges, and the chroma subsampling is why red text on a white background looks softer than black text at the same quality. PNG is lossless: it filters each row and then deflates the result, so it reproduces the exact pixels. That is superb for flat colour, text and screenshots, where long runs of identical pixels compress to almost nothing, and poor for photographs, where every pixel differs slightly and there is little repetition to remove. WebP has both modes: a lossy block transform derived from VP8, and a lossless mode that usually beats PNG on the same pixels. The browser chooses the mode from the quality value it is handed.
The same image, five encodings
To make the trade-off concrete, here is one 1200 × 800 image encoded five ways in Chrome's canvas encoder. The fixture is generated procedurally — a vertical gradient, sixty translucent circles and 120,000 pixels of ±18 noise — so it has both flat areas and fine detail, which is what makes the format differences visible.
| Encoding | Bytes | Relative to WebP q0.8 | What it is good for |
|---|---|---|---|
| PNG (lossless) | 850,524 | 13.3× | Screenshots, diagrams, transparency |
| JPEG q0.90 | 173,806 | 2.7× | Photographs where quality matters |
| JPEG q0.75 | 68,494 | 1.07× | Photographs for the web |
| JPEG q0.60 | 40,587 | 0.64× | Thumbnails and previews |
| WebP q0.80 | 63,750 | 1× | General web delivery with alpha |
Measured with canvas.toDataURL in Chrome (headless, 2026-10-24) on the fixture described
above. Browser encoders differ: Safari and Firefox produce different byte counts for the same quality
value, so treat these as ratios, not as constants to quote.
Two readings matter. First, the PNG is more than thirteen times the WebP — for a photographic image, lossless is a storage choice, not a delivery choice. Second, the quality slider is not linear: dropping JPEG from 0.90 to 0.75 removes 60% of the bytes, while 0.75 to 0.60 removes another 40% of what is left. The first drop is usually invisible on a screen; the second starts to show on gradients and fine text.
Why PNG is enormous for photographs
PNG's compression depends on repetition. A screenshot of a document is mostly white with repeated glyph shapes, so deflate finds long matches and the file is small. A photograph has a slightly different value in every pixel — sensor noise alone guarantees it — so there is very little exact repetition to encode, and the file ends up close to the raw pixel data. Converting a photo to PNG does not improve it; it just stores the same pixels less efficiently than JPEG or WebP would.
The exception is transparency. PNG and WebP have an alpha channel; JPEG has none. If a logo has a transparent background, converting it to JPEG fills that area with a solid colour — usually white, which is wrong on a dark page. Keep PNG or WebP when transparency is part of the design, and accept the larger file or reduce the dimensions instead.
Re-encoding is not free
JPEG and WebP are lossy at any quality below 100, and the loss is not reversible. Opening a JPEG and saving it again at the same quality discards a little more detail, and repeating that chain — screenshot to chat, chat to editor, editor to website — accumulates visible artefacts. The rule is to keep the original and re-export from it, never to “fix” a compressed file by compressing it again.
It is also why a re-encode can make a file larger. An already-compressed JPEG re-saved at a high quality has to spend bytes describing the compression artefacts of the first pass, and the result can exceed the input. If the goal is a smaller file and the source is already a compressed JPEG, the levers that still work are dimensions and a lower quality — not another high-quality pass.
A workflow that works
- Decide the display size first. Measure the slot the image will occupy and resize to that width (with a 2× version only if the slot is viewed on high-density screens). This is the biggest saving and it costs nothing visible.
- Choose the format by content, not by habit. Photographs: JPEG or WebP. Screenshots, diagrams and anything with text or transparency: PNG or lossless WebP. Icons and favicons: the format the platform requires (ICO for Windows, PNG for the web).
- Set quality by looking, not by number. Start around 0.75–0.85 for JPEG or WebP and compare at 100% on the part of the image with the most detail. If the difference is invisible, go lower; if it is visible, the saving is not free.
- If there is a hard size limit, search for it. The compressor on this site binary- searches the quality that fits a target in KB or MB, and only shrinks dimensions when quality alone cannot reach it.
The order matters. Compressing before resizing wastes effort on pixels that are about to be discarded; resizing before choosing a format means the format decision is made on the right amount of data.
What the browser will and will not do
Every image tool on this site uses the browser's own decoders and encoders. That has two consequences worth knowing. A format the browser cannot decode — HEIC from an iPhone on most desktops, for example — fails at the load step rather than producing a wrong result. And re-encoding through a canvas drops metadata: EXIF, including the orientation flag and GPS coordinates, does not survive. That is usually desirable before publishing a photo, but it means a photo that relies on its EXIF orientation must be oriented by the viewer before it is processed.