Keep a good source master, resize for the destination, choose a format that matches the content, then tune compression while looking at the actual result. Do not treat a quality number as a universal percentage.
Lossy and lossless compression make different promises
Lossless formats preserve the represented pixel information through encoding and decoding. Lossy formats intentionally discard, simplify, or approximate some information to reduce file size. Neither category is automatically better: each is useful for different content and delivery goals.
| Type | Useful for | Tradeoff |
|---|---|---|
| Lossy | Photos and compact delivery | Some image information is discarded; repeated re-encoding can add artifacts |
| Lossless | Graphics, text, screenshots, masters, transparency workflows | Can be much larger for complex photographic content |
JPG is the familiar lossy example. PNG is a familiar lossless example. WebP and AVIF can support more than one encoding mode depending on the tool and workflow.
What a quality slider actually means
A quality slider controls an encoder. It is not a standardized measurement of how much “quality” the image contains. A value of 80 in JPEG should not be treated as equivalent to 80 in WebP or AVIF, and even two different encoders for the same format can behave differently.
The useful question is not “What is the perfect quality number?” but “At the intended display size, is the visual result acceptable for the bytes it costs?”
- Inspect faces, text, fine texture, gradients, and hard edges after compression.
- Compare the output at normal viewing size, not only extreme zoom.
- Use representative images; one test photo does not describe every image.
- Keep the source file so you can export again instead of re-compressing an old delivery copy.
Generation loss matters
When a lossy image is decoded and encoded again, the new encoder works from pixels that already contain the effects of the earlier compression. Repeating that process can gradually add blockiness, ringing, smearing, or loss of fine detail.
This is why an original or high-quality master is valuable. Create a fresh delivery copy from the best available source rather than repeatedly converting yesterday's exported JPG into today's new JPG.
Saving a compressed JPG as PNG stops the new file from using JPEG compression, but it does not restore image information that the original JPG already lost.
Pixel dimensions can matter more than the format
A 6000-pixel-wide image displayed at 1000 pixels wastes transfer bytes and decoding memory even if it is encoded efficiently. Resizing to an appropriate delivery size often produces a larger practical win than changing the extension.
Dimensions also affect browser memory. A compressed file that is only a few megabytes on disk can expand dramatically when decoded into raw pixels. A 12,000 × 9,000 RGBA image represents more than 400 million bytes of raw pixel data before temporary encoder buffers and the WebAssembly runtime are counted.
That is one reason browser-first converters need sensible batch and memory limits. File size alone does not describe the cost of processing an image.
A practical image delivery workflow
- Keep a source master. Preserve the best original you have.
- Choose destination dimensions. Resize to what the website, email, app, or document actually needs.
- Choose the format by content. Photos, screenshots, transparency, and compatibility have different needs.
- Tune compression. Reduce file size while checking the visible result.
- Test the destination. Confirm the CMS, browser, recipient, or upload form accepts the output.
This approach is more dependable than hunting for one universal file format or one universal quality setting.
Common compression questions
Does a smaller image file always load faster?
Usually fewer transfer bytes help, but decode cost, caching, image dimensions, network conditions, and page layout also influence perceived performance.
Is quality 100 lossless?
Not necessarily. A maximum quality setting in a lossy encoder can still be lossy. The meaning depends on the codec and implementation.
Should I convert every image to the newest format?
No. Compatibility, editing workflow, transparency, content type, tooling, and actual visual results all matter.
Why can a tiny JPG use a lot of memory?
Compressed disk size and decoded pixel memory are different things. Large dimensions can require hundreds of megabytes after the image is expanded for processing.