Converting a JPEG to a PNG is one of those operations that sounds straightforward and is full of subtle traps. The conversion itself is mechanically simple: decode the JPEG, encode the resulting pixel buffer as PNG. The traps are everywhere else. Color profiles get stripped. Bit depth quietly shifts from 8-bit per channel to something else. ICC tags vanish. Alpha channels appear where none existed. EXIF orientation flags get applied to the pixels in some tools and ignored in others. Compression artifacts that were invisible in the JPEG become visible in the PNG because the displayer rendered the two files differently.

The result is that "JPEG to PNG" performed naively can produce a PNG that looks worse than the source JPEG, even though the pixel data is technically identical. This article explains why, and walks through the specific operations that produce a faithful PNG copy of a JPEG source.

What JPEG to PNG Conversion Actually Does

A JPEG file contains a compressed representation of an image. When decoded, the JPEG produces a pixel buffer of YCbCr or RGB values, typically at 8 bits per channel. PNG conversion takes that pixel buffer and encodes it as DEFLATE-compressed RGB or RGBA, also typically at 8 bits per channel.

The key word is "decoded." The JPEG-to-PNG operation is lossless from the decoded pixel buffer to the PNG file. It is not lossless from the original captured scene; that loss happened during the original JPEG encode and cannot be undone.

This is the first principle of quality-preserving conversion: your output PNG can only be as good as your decoded JPEG. The work is to make sure the decoded JPEG is faithful to the source file (correct color, correct bit depth, correct orientation) and that the PNG encode preserves that fidelity.

"Format conversion is a translation, not a restoration. Preserving quality means preserving what the source file actually contained, not what you wish the source had captured." Andrew Rodney, color management consultant and author of Color Management for Photographers

The Five Failure Modes

Naive JPEG-to-PNG conversion fails in five recurring ways. Each is preventable with the right tooling configuration.

FailureCauseVisible SymptomFix
Stripped color profileTool defaultColor shift in color-managed appsPreserve ICC during conversion
Wrong gammaImplicit sRGB assumptionSlightly washed out or contrastyHonor source gamma
Lost EXIF orientationPixels not rotatedImage displays sidewaysApply orientation, then strip tag
Banding from quantizationDecoder dithering disabledVisible bands in gradientsDecode at higher precision
Alpha channel ghostingTool adds alpha channelHalos around image edgesStrip alpha if source has none
These failures are the difference between "conversion works" and "conversion preserves quality."

Color Profile Preservation

The ICC profile is the most important single piece of metadata in modern image files. It defines the mapping from numerical pixel values to actual colors. A pixel value of (200, 100, 100) in sRGB is a different color from the same value in Display P3 or ProPhoto RGB. If the conversion strips the ICC profile, the receiving application falls back to a default (usually sRGB), which produces visible color shifts when the source was in a different color space.

Modern smartphone JPEGs frequently embed Display P3 profiles. Photo editing tools often produce ProPhoto RGB or Adobe RGB JPEGs. Stripping these profiles during conversion is a common cause of "the colors look different" complaints.

The right tooling configuration preserves the profile by default:

# ImageMagick: preserve ICC profile, strip everything else
magick photo.jpg \
  -profile "$(magick photo.jpg -format '%[profile:icc]' info:)" \
  -strip \
  +profile '!icc,*' \
  photo.png

# A simpler invocation that just preserves all profiles
magick photo.jpg photo.png

# libvips via command line
vips copy photo.jpg photo.png

ImageMagick's default behavior is to preserve profiles. The earlier strip pattern explicitly preserves only the ICC profile while removing other metadata; this is the right choice for distribution copies where EXIF is not desired.

For programmatic workflows, Pillow and Sharp both preserve ICC profiles when configured correctly:

# Pillow: preserve ICC and embed in PNG
from PIL import Image

img = Image.open("photo.jpg")
icc = img.info.get("icc_profile")

img.save(
    "photo.png",
    format="PNG",
    icc_profile=icc,
    optimize=True
)

// Sharp: preserve ICC profile during conversion
import sharp from 'sharp';

await sharp('photo.jpg')
  .withMetadata({ icc: 'sRGB' }) // or pass the actual profile
  .png({ compressionLevel: 9 })
  .toFile('photo.png');

Bit Depth and Precision

JPEG is 8-bit-per-channel by default; the JPEG-XT extension supports higher bit depths but is rarely used. PNG supports 8 or 16 bits per channel. For most JPEG-to-PNG conversion the right output bit depth is 8.

Two cases justify 16-bit PNG output:

  1. The image will be edited further. Higher bit depth gives editing tools more headroom for tonal adjustments without banding.
  2. The image is going into an HDR pipeline. 16-bit PNG with a wide-gamut profile preserves dynamic range that 8-bit cannot.

In both cases, decode the JPEG at higher internal precision before encoding to 16-bit PNG:

# ImageMagick: decode JPEG at 16-bit, write 16-bit PNG
magick photo.jpg -depth 16 -define png:bit-depth=16 photo.png

# libvips equivalent
vips cast photo.jpg photo.png[bitdepth=16] ushort

Naive conversion at 8-bit can introduce banding in subtle gradients (skies, skin tones, large flat areas). The fix is decoding at higher precision and downsampling to 8-bit only when the output target requires it.

Handling EXIF Orientation

JPEG files can store an EXIF orientation tag indicating the image should be rotated when displayed. Most image viewers honor this tag. Most image editing tools also honor it. PNG does not have an equivalent tag; orientation must be baked into the pixel data.

The conversion mistake is to strip EXIF without first applying the rotation. The result is an image that displays sideways or upside-down compared to the original.

# ImageMagick: apply EXIF rotation, then strip metadata
magick photo.jpg -auto-orient -strip photo.png

# Pillow with explicit orientation handling
python3 -c "
from PIL import Image, ImageOps
img = Image.open('photo.jpg')
img = ImageOps.exif_transpose(img)
img.save('photo.png')
"

Always test conversion with portrait-mode phone photos; they are the most common source of orientation bugs.

Alpha Channel Discipline

JPEG does not support alpha. PNG does. A naive conversion may add an unnecessary alpha channel (filled with 255 everywhere) which inflates the file size and can cause halos when the PNG is rendered against a different background than the original was designed for.

The default should be to keep PNG output in RGB mode (no alpha) when the source has no alpha. Force RGBA only when transparency is genuinely required.

# ImageMagick: force RGB output, no alpha
magick photo.jpg -alpha off PNG24:photo.png

# Force RGBA with explicit transparency
magick photo.jpg -alpha set PNG32:photo.png

The PNG24 and PNG32 prefixes are ImageMagick conventions: PNG24 produces 8-bit RGB, PNG32 produces 8-bit RGBA. Without an explicit prefix the tool may pick either based on the alpha channel state.

File Size Realism

The most common surprise after JPEG-to-PNG conversion is the file size. A 200 KB JPEG photograph often converts to a 1.5 MB PNG. This is not a bug. JPEG achieved its small size by discarding information; PNG faithfully preserves whatever information remains. For photographic content with continuous tones, lossless compression cannot match lossy compression.

Source ImageJPEG SizePNG SizeRatio
1080p photograph240 KB2.1 MB8.7x
1080p screenshot95 KB220 KB2.3x
Logo on solid background12 KB8 KB0.7x
Detailed illustration380 KB920 KB2.4x
Solid color region18 KB4 KB0.2x
The pattern is predictable: PNG beats JPEG for solid colors, indexed palettes, and line art. JPEG beats PNG for continuous tones. PNG conversion makes most sense for screenshots and graphics, less sense for photographs.

For photographs that must be lossless, JPEG XL's lossless mode and lossless WebP are usually 30 to 50 percent smaller than PNG, with the same pixel-exact preservation.

When Conversion Is Worth Doing

Despite the size penalty, JPEG-to-PNG conversion is the right move in several common scenarios.

Edit-then-re-save workflows. Editing a JPEG, saving as JPEG, opening, editing, saving as JPEG again is the canonical generation-loss disaster. The fix is to convert to PNG (or any lossless format) immediately, do all editing in the lossless format, and re-encode to JPEG only at distribution time.

Compositing with transparency. Adding a logo or transparent overlay requires alpha. Convert to PNG (or PSD/TIFF), composite, and re-render.

Archival of source-of-truth assets. Even if the canonical original is a JPEG, converting to PNG creates a stable working copy that will not accumulate further generation loss through editing.

Print preparation. Print pipelines often require lossless input to avoid moiré patterns from JPEG block boundaries interacting with print screens.

Pixel-exact comparison. Visual regression testing tools require pixel-exact images. Converting to PNG locks the pixel state.

For other cases (web delivery, distribution, sharing), keeping the JPEG or converting to AVIF/WebP is usually a better choice than converting to PNG.

"The reason to convert lossy to lossless is to stop the bleeding. You cannot recover what JPEG threw away, but you can prevent further loss in everything you do next." Eric Reagan, photography educator, in a 2019 interview on workflow archiving

A Production Conversion Script

The following script handles the common edge cases: it preserves ICC, applies EXIF rotation, strips other metadata, decodes at high precision, and outputs optimized PNG.

#!/usr/bin/env bash
set -euo pipefail

INPUT="$1"
OUTPUT="${INPUT%.*}.png"

# Conversion with full quality preservation
magick "$INPUT" \
  -auto-orient \
  -depth 16 \
  +profile '!icc,*' \
  -define png:bit-depth=8 \
  -define png:compression-level=9 \
  PNG24:"$OUTPUT"

# Lossless post-processing optimization
oxipng --opt max --strip safe --zopfli "$OUTPUT"

# Verify pixel content
echo "Source SHA: $(magick "$INPUT" -depth 8 RGB:- | sha256sum)"
echo "Output SHA: $(magick "$OUTPUT" -depth 8 RGB:- | sha256sum)"

The two SHA values should match in the absence of color profile transforms or bit-depth changes. If they do not match, the pixel data changed during conversion, and the difference deserves investigation.

For a Python pipeline:

from pathlib import Path
from PIL import Image, ImageOps

def convert_jpeg_to_png(src: Path, dst: Path) -> None:
    img = Image.open(src)
    icc = img.info.get("icc_profile")
    img = ImageOps.exif_transpose(img)
    img.save(
        dst,
        format="PNG",
        icc_profile=icc,
        optimize=True,
        compress_level=9
    )

if __name__ == "__main__":
    import sys
    src = Path(sys.argv[1])
    convert_jpeg_to_png(src, src.with_suffix(".png"))

Verification and Audit

After conversion, three checks confirm the operation preserved quality.

Color profile check. Use exiftool or Pillow to confirm the output PNG carries an ICC profile.

exiftool -ICC_Profile -ColorSpace photo.png

Pixel-level diff. Compare the decoded pixel buffer of source and output. With color management held constant, they should be identical.

magick compare -metric AE photo.jpg photo.png null:

A value of zero confirms pixel-exact conversion. Any non-zero value indicates a transform happened during conversion.

Visual rendering. Open both files in a color-managed viewer (such as Photoshop, Affinity, or Firefox) and compare side by side. If they look different, the conversion is wrong.

For batch operations, automate these checks. A pipeline that silently corrupts color profiles across thousands of files is a problem only discovered downstream.

Format Choice After Conversion

Once a JPEG has been converted to PNG, three onward paths matter.

  1. PNG as final delivery. Reasonable for screenshots and UI, oversized for photographs.
  2. PNG as working master, AVIF/WebP for delivery. The right choice for web pipelines. Edit in PNG, deliver in AVIF.
  3. PNG as archival, JPEG XL or WebP lossless for distribution. Smaller than PNG with bit-exact preservation.

For deeper guidance on choosing among formats, the SVG vs PNG vs JPG comparison and the essential guide to choosing the right image format on this site cover the trade-offs in detail. Sites operating large image pipelines, including the wildlife galleries at strangeanimals.info and the cafe imagery at downundercafe.com, benefit from formal master-and-derivative pipelines built around lossless PNG or JPEG XL masters.

Common Misconceptions

Three persistent misconceptions are worth correcting explicitly.

"PNG conversion improves a low-quality JPEG." It does not. The JPEG artifacts are baked into the pixel data. PNG faithfully preserves them. Improving image quality requires denoising or super-resolution, not format conversion.

"PNG is always better than JPEG." PNG is better at lossless preservation. JPEG is dramatically better at file size for photographic content. Neither dominates; choose based on use case.

"Converting back and forth is harmless." JPEG to PNG to JPEG is harmless if the second JPEG encode happens once at sufficient quality. JPEG to PNG to JPEG to PNG to JPEG, with edits between, accumulates compounding loss in the JPEG stages.

The right mental model treats format choice as part of pipeline architecture, not as a per-file decision. Pick the formats that match your storage, editing, and delivery patterns; convert deliberately and only when the workflow requires it.

Edge Cases Worth Naming

Several edge cases produce surprises during JPEG-to-PNG conversion and deserve explicit attention.

Progressive JPEGs. Some decoders produce slightly different pixel output for progressive JPEGs versus baseline JPEGs of the same content. The differences are usually within rounding error, but pixel-exact pipelines should test both.

Non-standard chroma subsampling. JPEG files with 4:4:4 chroma decode differently than 4:2:0 files. PNG conversion is unaffected (PNG is RGB), but the source quality differs.

Embedded thumbnails. EXIF often contains a small JPEG thumbnail. Some tools pick up the thumbnail rather than the main image when the file structure is unusual. Solution: explicit decoder flags or trusted libraries.

CMYK JPEGs. JPEG can store CMYK color, common in print workflows. PNG is RGB only. Conversion requires color space transformation, which depends on the ICC profile. Without proper handling, colors shift.

Lossy alpha (JPEG-XR, HEIC). Some lossy formats support alpha. Converting these to PNG preserves the alpha. Converting to JPG forces the alpha to be flattened against a background color.

Each edge case is rare in normal workflows but routine in specialized pipelines. The right defensive posture is to verify pixel content after conversion on representative samples.

Final Operational Discipline

The single most reliable practice for high-quality JPEG to PNG conversion is to keep both files. Run the conversion, verify the output against the source, and store both. The PNG is the working copy for editing. The JPEG is the canonical original. If the conversion turns out to have failed in some way, the original is intact. This costs storage but eliminates an entire category of irrecoverable error.

References

  1. ISO/IEC 15948:2004, Information technology, Computer graphics and image processing, Portable Network Graphics (PNG): Functional specification. https://www.iso.org/standard/29581.html
  2. International Color Consortium, Specification ICC.1:2010 Image technology colour management, Architecture, profile format, and data structure. https://www.color.org/specification/ICC1v43_2010-12.pdf
  3. ITU-T Recommendation T.81, Information technology, Digital compression and coding of continuous-tone still images, Requirements and guidelines, 1992. https://www.itu.int/rec/T-REC-T.81
  4. W3C, PNG Specification (Third Edition) Working Draft, 2024. https://www.w3.org/TR/png-3/
  5. ImageMagick Studio, ImageMagick Command-Line Reference. https://imagemagick.org/script/command-line-options.php
  6. Library of Congress, PNG, Portable Network Graphics format description. https://www.loc.gov/preservation/digital/formats/fdd/fdd000153.shtml
  7. Hubbell, Greg. The Pillow Image Library Documentation, version 10.x. https://pillow.readthedocs.io/en/stable/
  8. CIPA DC-008-2024, Exchangeable image file format for digital still cameras: Exif Version 3.0. Camera and Imaging Products Association. https://www.cipa.jp/std/documents/e/DC-X008-Translation-2024-E.pdf