Why Your Converted JPG Is Bigger Than the PNG

You dropped a PNG into a converter expecting a smaller file, and the JPG came out bigger. It feels backwards — JPEG is the "compressed" format, right? The catch is what was inside the PNG. If it was a screenshot, logo, or UI capture, PNG was already the efficient choice, and re-encoding it as JPEG only adds bytes and blur. Here's exactly why that happens, and how to get a genuinely smaller file.

#TL;DR

• PNG is lossless and crushes flat color; JPEG is built for photos.
• Screenshots, logos, and diagrams compress smaller as PNG than JPG.
• High JPEG quality carries block-transform overhead PNG never pays.
• To shrink the file: lower JPEG quality, or use WebP/AVIF instead.
• If the source is a graphic, optimize the PNG — don't convert it.

#Why is my converted JPG bigger than the PNG?

The short answer: the two formats are good at opposite things, and you handed JPEG the kind of image PNG was designed for.

#PNG is lossless but optimized for flat color

PNG stores every pixel exactly, then compresses the result with the DEFLATE algorithm plus per-row filtering, as defined in the W3C PNG specification. DEFLATE is a dictionary compressor: it thrives on repetition. A screenshot with a 600-pixel-wide band of identical #FFFFFF collapses into a tiny run, because PNG's filters turn long stretches of the same color into long runs of zeros that DEFLATE encodes in a handful of bytes.

So "lossless" does not mean "large." For the right content, PNG is both perfect and small. As web.dev's image guide puts it, PNG "does not apply any lossy compression algorithms beyond the choice of the size of the color palette" — which is exactly why an 8-bit indexed PNG of a logo can be a few kilobytes.

#JPEG was built for photographs, not screenshots

JPEG works in a completely different way. It splits the image into 8×8 pixel blocks, runs a Discrete Cosine Transform on each block, and quantizes the frequency coefficients — the process standardized in ITU-T T.81. That math is brilliant for photographs, where neighboring pixels vary smoothly and the eye won't notice small rounding in high-frequency detail.

It is the wrong tool for a screenshot. Sharp text and crisp UI edges are all high frequency. JPEG can't represent a hard black-on-white edge cheaply, so it spends coefficients trying — and still leaves visible "ringing" around the letters. MDN's format guide warns that applying lossy compression to content requiring sharpness, like diagrams or charts, can produce unsatisfactory results. You pay in bytes and in quality.

#Quality 100 JPEG carries overhead PNG never pays

Most converters default to a high JPEG quality — 90, 95, even 100 — to avoid obvious artifacts. But a near-lossless JPEG keeps most of those DCT coefficients, and every 8×8 block still carries its own quantized data plus Huffman tables and headers. On a flat image there's almost nothing to compress, so all that machinery becomes pure overhead. The result: a JPG that's larger than the PNG it replaced, and slightly blurrier too.

#When PNG wins and when JPEG wins

The format isn't "better" or "worse" in the abstract — it depends entirely on the picture's content.

#Screenshots, logos, and UI: PNG territory

If the image is made of solid fills, flat gradients, sharp lines, or text, PNG (or lossless WebP) will almost always be smaller and look crisper. This covers app screenshots, exported charts, icons, line art, and anything with transparency — JPEG has no alpha channel at all, so a transparent PNG can't even round-trip through JPG without losing its transparency.

#Photographs and gradients: JPEG territory

If the image is a photo — a face, a landscape, a product shot full of subtle tonal variation — JPEG (or lossy WebP/AVIF) will crush it far below what PNG can manage, with no visible loss at a sensible quality. A 24-bit photographic PNG is often huge; that's the case where converting to JPG genuinely pays off.

#A quick size-comparison cheat sheet

The rule of thumb: few colors and sharp edges → PNG; many colors and smooth tone → JPEG.

#How to actually make the file smaller

If your goal is just a smaller file — not specifically a .jpg — you have better options than a high-quality JPEG.

#Lower the JPEG quality setting

If you do need JPEG, the single biggest lever is quality. Dropping from 100 to around 80 typically cuts the file dramatically with no visible difference on photos. web.dev recommends trying several JPEG quality levels to find the best quality-versus-size tradeoff. In a browser, the quality argument lives in the second parameter of canvas.toBlob:

canvas.toBlob(
  (blob) => download(blob),
  "image/jpeg",
  0.8 // quality: 0.0–1.0, try 0.75–0.85
);

Anything above ~0.92 keeps so much detail that flat images barely shrink — that's the "quality 100" trap again.

#Try WebP or AVIF instead of JPG

For most images in 2026, the right answer isn't JPEG at all. WebP and AVIF beat both older formats: lossless WebP is typically smaller than PNG for graphics, and lossy WebP/AVIF undercut JPEG for photos. A quick command-line check makes the difference obvious:

# compare three encodings of the same source
ls -l shot.png            # original
cwebp -lossless shot.png \
  -o shot.webp            # lossless WebP
cwebp -q 80 shot.png \
  -o shot-lossy.webp      # lossy WebP

You can do the same conversion without installing anything using the in-browser Image Format Converter, which keeps every file on your own machine.

#Optimize the PNG instead of converting it

If the source is a graphic, the smartest move is often to leave it as PNG and just optimize it — reduce a 24-bit PNG to an 8-bit indexed palette, strip metadata, and re-run the compressor. That can halve the size while staying lossless. For batch work, a dedicated image compressor will do palette reduction and re-encoding across many files at once. Converting to JPEG to "save space" on a logo is solving the wrong problem.

#How to stop a converted JPG from getting bigger

The fix is mostly diagnostic: decide what kind of image you have before you pick a format.

#Check what kind of image you have first

Ask one question: is this a photograph, or a graphic? Open the image and look at a flat region up close. If it's a single uniform color, it's a graphic — keep it as PNG or WebP. If even the "flat" areas show subtle pixel-to-pixel variation, it's photographic and a good JPEG candidate. This 10-second check prevents almost every "my JPG got bigger" surprise.

A few practical tells that you're holding a PNG-friendly image:

• It came from a screenshot tool or a screen capture.
• It has hard edges, text, or a transparent background.
• It uses a small, deliberate set of brand colors.
• Zooming in shows crisp boundaries, not photographic grain.

#Don't convert lossless graphics to JPEG at all

If the image is a graphic, there is no JPEG quality setting that wins. At high quality you get a bigger file; at low quality you get visible artifacts around every edge. The honest answer is to skip the conversion. JPEG's combination of lossy and lossless steps is tuned for tonal photographs — feeding it flat color is working against the format's entire design.

#Re-encoding adds artifacts and bytes

Every time you push an image through a lossy encoder, you bake in new artifacts that the next encoder then has to spend bytes describing. Convert a clean PNG to JPEG and the sharp edges sprout ringing; convert that JPEG again and the artifacts compound. If you're only resizing or cropping a graphic, do it in a tool that preserves the original format — for example, resizing a UI asset with an image resizer rather than round-tripping it through JPEG each time.

#The bottom line

A JPG that's bigger than its PNG source isn't a bug — it's the formats behaving exactly as designed. PNG already won, because the image was the flat, sharp-edged kind PNG was built for. Match the format to the content: graphics stay lossless (PNG or WebP), photographs go lossy (JPEG, WebP, or AVIF). Do that, and "my converted file got bigger" stops happening.

#References

• Image file type and format guide — MDN; cited for JPEG's poor results on sharp content like diagrams and charts.
• Choose the right image format — web.dev; used for PNG's lossless behavior and JPEG quality-vs-size guidance.
• Portable Network Graphics (PNG) Specification — W3C; reference for DEFLATE compression and per-row filtering.
• JPEG (ITU-T T.81) — the JPEG standard; cited for 8×8 DCT and coefficient quantization.

#Related on iKit

• PNG vs JPG vs WebP vs AVIF: which format to actually use — the full decision guide behind the cheat sheet above.
• How to convert JPG to PNG — and when you shouldn't — the reverse direction, with the same content-type logic.
• Convert PNG to JPG without a black background — what happens to transparency when you go PNG → JPG.
• Convert PNG to WebP and cut image size by 30% — the lossless-WebP route that usually beats both PNG and JPG.
• Convert images to AVIF — and when AVIF beats WebP — the newest format for the photographic side of the table.
• WebP vs AVIF encoding: support, size, and speed — picking between the two modern codecs once you've left JPEG behind.
• Compress PNG without losing quality — optimize the graphic instead of converting it.