PNG uses lossless compression — specifically a combination of filtering and DEFLATE, which is the same algorithm inside ZIP files. For images with large areas of solid color, gradients between a limited number of values, or repeating patterns, DEFLATE is very efficient. A flat logo on a white background might compress to a few kilobytes in PNG because there's genuinely very little variation for the algorithm to store. A photograph is the opposite problem. Every pixel in a photo has slightly different values from its neighbors because of natural texture, film grain, sensor noise, and the complex lighting of the real world. DEFLATE has almost nothing to compress. That's why a photograph saved as PNG ends up being enormous — you're storing essentially all of the raw pixel data with very little reduction.
JPEG takes a completely different approach. It converts the image from RGB color values to a frequency-based representation using the discrete cosine transform, then discards the high-frequency detail that human vision is least sensitive to. What remains is stored efficiently. This is why JPEG is so good at photographs specifically: the detail it discards is the same fine high-frequency noise that DEFLATE couldn't compress anyway. You're not losing anything your eye would have noticed at normal viewing sizes. The 60 to 80% size reduction isn't magic — it's the difference between storing everything and storing only what matters perceptually.
The one case where PNG-to-JPG goes wrong: text and screenshots
JPEG's frequency-based compression works against it on images with hard edges and sharp transitions — exactly what you get with text, UI screenshots, diagrams, and line art. Where a photograph has smooth transitions between colors that the DCT handles well, a screenshot has abrupt pixel-level boundaries. JPEG encodes these boundaries as ringing artifacts: faint halos and blurring around edges that are most visible around dark text on a light background. Even at quality 95, a screenshot of a document or a UI design will look noticeably worse as a JPEG than as a PNG, and the file size advantage shrinks considerably because screenshots contain the kind of repeating patterns and flat areas that DEFLATE compresses well.
If you have a PNG that's a mix of photographic content and text — a product photo with a label, for instance, or a screenshot with an embedded image — JPEG at quality 85 to 90 is usually acceptable. The artifacts around text will be subtle enough to not matter for most uses. Where it becomes a problem is very small text, dark text on white backgrounds at high contrast, or any context where the image will be zoomed in on. For those cases, staying with PNG or converting to WebP (which uses a more modern compression approach that handles edges better) is the right call.
What MozJPEG does differently from standard JPEG
Standard JPEG encoding, as implemented in most software, leaves some compression efficiency on the table. Mozilla's MozJPEG encoder applies additional optimization passes — specifically trellis quantization and improved Huffman coding — that find a better way to represent the same visual quality in fewer bytes. The result is typically 10 to 15% smaller than a standard JPEG encoder at the same quality setting, with no difference in how the image looks. This matters because MozJPEG output is fully compatible with every JPEG decoder. A browser, an image viewer, or a photo app opening a MozJPEG file sees a standard JPEG. The only difference is that it got there more efficiently. If you need to go even smaller after converting, the compress to 100KB tool can target a specific file size using the same binary search approach on top of MozJPEG encoding.