The short answer: JPG is a lossy format built for photographs, and PNG is a lossless format built for graphics. A photo saved as PNG wastes megabytes for zero visible gain. A screenshot saved as JPG comes out with smeared text and fuzzy edges. Everything else in the debate — file size, transparency, editing behavior — follows from how each format compresses. So let's look at that.
How JPG compresses: throw away what you won't miss
JPEG has been around since 1992 (the history of JPG covers where it came from), and its trick is still the same. The encoder splits the image into 8×8 pixel blocks and runs each through a discrete cosine transform, turning pixel values into frequencies. Smooth gradients become a few strong low-frequency coefficients. Fine detail becomes weak high-frequency coefficients — and those are exactly what the quantizer discards.
Two more decisions fall out of how eyes work. Color resolution is halved (chroma subsampling), because humans are far more sensitive to brightness detail than color detail. And the quality slider is just the aggressiveness of that quantizer: 90 keeps almost everything visible, 60 starts throwing away things you will notice.
Two hard limits to remember: JPG is 8-bit per channel, and it has no alpha channel. Transparency cannot survive a JPG save.
The other consequence: every save re-runs the quantization. Open a JPG, edit it, save it, and you have thrown away another slice of detail. Do that ten times and the image visibly rots — blocky skies, halos around edges. This is generation loss, and it is why JPG is a delivery format, not a working format.
How PNG compresses: keep every pixel, at any cost
PNG arrived in the mid-1990s as a patent-free replacement for GIF (the birth of PNG tells that story), and its philosophy is the opposite of JPEG's: not one pixel may change.
The pipeline has two stages. First, each row of pixels is passed through a predictor filter — Sub, Up, Average, or Paeth — chosen per row to make the data as repetitive as possible. Then the filtered bytes go through DEFLATE, the same LZ77-plus-Huffman compression family that ZIP files use. Nothing is approximated. Decompression reproduces the original bytes exactly.
That buys three things. Full alpha transparency (8 bits of it, versus GIF's single on-or-off transparent color). Optional 16-bit color depth. And immunity to generation loss: save a PNG a hundred times and the pixels are bit-for-bit identical. The cost shows up the moment you feed it a photograph. Photo pixels are noisy — every pixel differs slightly from its neighbors — and noise is the one thing DEFLATE cannot compress.
The size reality
Same source images, both formats:
| Image | JPG (q90) | PNG |
|---|---|---|
| 12 MP photo | ~3.4 MB | ~20 MB |
| 1920×1080 UI screenshot | ~600 KB | ~250 KB |
| Logo with transparent bg | not possible | ~40 KB |
Read the table twice, because both directions matter. The photo is roughly six times larger as PNG with no visible improvement. The screenshot is smaller as PNG and sharper, because flat colors and sharp edges are exactly what DEFLATE's predictors eat for breakfast — and exactly what JPEG's quantizer mangles. The formats are not better and worse. They are optimized for opposite kinds of data.
Three mistakes people keep making
Saving screenshots and UI images as JPG. Text and hard edges are high-frequency content, which is the first thing the quantizer discards. The result is "mosquito noise" — a faint dirty halo around every letter. If the image came off a screen, it belongs in PNG.
Saving photos as PNG "for better quality." PNG does preserve more, but the difference is invisible for a photo at normal viewing sizes, and you pay six times the bytes for it. If a photo is headed to a website or an email, PNG is the expensive way to get the same picture.
Editing in JPG. Every intermediate save costs detail. The fix is to keep the working file in PNG and export JPG once, at the end. Converting a finished JPG to PNG later does not restore anything — it just freezes the damage in place. The mechanics behind all of this are in our explainer on lossy vs. lossless compression.
Which format for which job
| Job | Use | Why |
|---|---|---|
| Photos on the web | JPG | smallest honest size for photos |
| Screenshots, UI mockups, text images | PNG | sharp edges stay sharp, smaller file |
| Logos, icons, anything transparent | PNG | JPG has no alpha channel |
| Editing and intermediate saves | PNG | no generation loss |
| Email attachments, print submission | JPG | universal, small enough to send |
| Flat-color web graphics | PNG | compresses better than JPG here |
If you are choosing formats for a website, both may be the wrong answer: WebP usually beats each at its own game. The head-to-heads are in WebP vs. JPG and WebP vs. PNG.
When you need to convert
Conversion is one-directional in what it can fix. PNG to JPG shrinks a photo to a fraction of the size and flattens any transparency onto a white background — the right move before uploading to an old form or emailing a batch. JPG to PNG freezes the current pixels in a lossless container so further editing stops the rot; it cannot bring back detail the JPG already threw away, and if transparency is what you need, converting JPG to PNG with transparency explains what is actually possible.
Both converters run locally in your browser — drop the files, get the results, nothing uploaded. The table above tells you which direction your file should travel.