Convert JPG to PNG on Mac

Between one and a half and fifteen times, and the multiplier is set by how hard the JPEG was squeezed. This is the opposite of what people expect: the worse the JPEG, the bigger the PNG.

Look at the last three rows and notice that the PNG barely changes: 228,851 then 239,064 then 239,892, going up as the JPEG gets worse. PNG’s DEFLATE stage finds runs of repeating pixels. A heavily compressed JPEG has fewer clean runs, not more, because quantization sprays 8 × 8 block artifacts across every flat area that used to be one solid color. The PNG then dutifully stores all of it, exactly.

Count the colors and the mechanism is unmistakable. The lossless original of the photograph holds 72,079 unique RGB values. The quality 85 JPEG made from it holds 106,669. The lossy step did not throw colors away, it invented 34,590 new ones as ringing and blocking. That noise is what your PNG is paying for.

No. Not partially, not a bit, not in any measurable sense.

A JPEG to PNG conversion is two steps: decode the JPEG to pixels, then store those pixels losslessly. The pixels that land in the PNG are exactly what the JPEG decoder handed over. Run both halves through one decoder and the proof is trivial: the quality 85 JPEG decoded and written straight back out as PNG produced a 496,370-byte file with a maximum per-channel difference of 0 against the decoded JPEG. Identical. Not visually identical, literally identical, at 4.42 times the bytes.

Against the true lossless original, the numbers only ever move the wrong way:

The small drop in each row is decoder disagreement, not new damage: ImageIO and libjpeg reconstruct chroma slightly differently and differed by up to 32 levels on a single pixel. The honest reading is that switching JPEG decoders moves more pixels than “upgrading to a lossless format” ever will, and neither one adds a single bit of detail back.

One more thing the conversion will not give you: transparency. The PNG from a JPEG reports hasAlpha: no and samplesPerPixel: 3. JPEG has no alpha channel to carry, so there is nothing for PNG to inherit. Removing a background is an editing job in Preview’s markup tools, Pixelmator or Photoshop. It is not a format setting. The same misconception in reverse is what makes PNG to JPG conversions come out with black backgrounds and halos.

Because it is storing the damage as if it were detail. The clearest single number on this page:

The round trip ended up 7,776 bytes larger than the lossless original, a 1.4% increase, while holding strictly less information than it. You paid full lossless price for a lossy picture. If the original still exists somewhere, use it and delete the JPEG. If it does not, keep the JPEG. Converting it to PNG preserves the artifacts at a five-times markup and preserves nothing else.

The one situation where this trade is defensible: the JPEG is now a master that will be re-edited and re-exported several times, and you want to stop adding generations of loss. Every JPEG save is another quantization pass. Freezing the current state as PNG halts that, at a cost you can now put a number on.

Three routes, nothing to install. There is no quality decision to make, because PNG has no quality setting.

# a whole folder
mkdir -p png
sips -s format png *.jpg --out png/

# one file, and cap the long edge while you are there
sips -s format png -Z 2000 photo.jpg --out photo.png

sips prints a suffix warning per file and exits 0. If the directory in --out does not exist it will not create one and will not complain, so run mkdir -p first. That trap and the rest of the sips behaviour is documented in the PNG to JPG guide.

Preview is the graphical route: open the JPEG, File → Export As…, choose PNG, save. With several images open in one window and multiple thumbnails selected, the menu item becomes Export Selected Images… and handles them together.

Finder handles it without either, via an Automator Quick Action built around Change Type of Images. Put a Copy Finder Items action in front of it: the conversion action replaces the originals in place.

Smol converts the same files 9.9% smaller than sips at identical pixels, and losslessly: 112,427 → 509,424 on the photograph against sips at 565,372, and 137,263 → 206,037 on the screenshot against 228,851, with a maximum per-channel difference of 0 against the decoded source in both cases. Worth having on a batch of a few hundred files. Not worth opening an app for one.

Often. The argument on this page is against JPEG to PNG, not against PNG, and those are different claims.

Screenshots and UI captures. Measured on the same 1440 × 900 app window: 85,257 bytes as PNG against 137,263 bytes as a quality 85 JPEG. The PNG is 37.9% smaller and pixel-perfect, with none of the faint ringing JPEG leaves around text. If you have screenshots stored as JPEG, that is a bug worth fixing at the source, which is usually a tool set to the wrong export format.

Line art, logos, diagrams and charts. Large flat areas and hard edges are precisely what DEFLATE compresses well and what the discrete cosine transform handles badly.

Anything that needs an alpha channel downstream. If the asset will be composited over an unknown background, it needs transparency, and JPEG cannot carry it. The transparency has to be created in an editor first, but PNG is the right place to keep it once it exists.

Editing masters. A file that will be opened, adjusted and re-exported repeatedly should not collect a fresh generation of lossy compression on every pass.

For anything web-facing there is now a better answer than either. Lossless WebP beat PNG by 72% on a retina screenshot while staying pixel-identical, and it keeps the alpha channel. PNG is still the safest interchange format, and it is no longer the efficient one.

For one file, use Preview or sips. Genuinely. PNG has no quality setting, so there is no decision for an app to help you make, and both are already on your Mac. sips -s format png photo.jpg --out photo.png is the whole job.

If you are doing this to fix a bad JPEG, stop. No tool on this page, ours included, can recover what the JPEG discarded. Find the original, re-export from the source file, or accept the JPEG as it is.

If the goal is a smaller file, this is the wrong operation entirely. Converting JPEG to PNG multiplies the size by five. What you want is compression, with the format left alone.

Smol earns the $29 on the recurring case: a few hundred mixed JPEG, HEIC and TIFF files that all have to come out as PNG for a design handoff or an asset pipeline, from Finder, roughly 10% smaller than the built-in encoder, with nothing uploaded and no per-file dialog. It is a one-time purchase and it runs offline.

Related: PNG to JPG and the transparency problem, HEIC to PNG, which has the same size trap, WebP to JPG, TIFF to JPG, and the full format reference.