Convert a PNG to JPEG

What this does

Turns a PNG into a JPEG without it leaving your computer, and asks you the one question that every other converter answers for you badly: what colour should the transparent parts become?

That question exists because JPEG stores three colour channels and no transparency. A PNG with a see-through background still has colour values underneath those pixels, and in a file exported from a design tool they are almost always zero. Drop the alpha channel without doing anything else and the zeros become visible — which is why a logo converted carelessly arrives as a white mark on a black rectangle.

The method

There are two codecs here and neither is the browser’s.

The obvious way to build this is createImageBitmap into an OffscreenCanvas and out through convertToBlob. It is four lines, and it was rejected. The HTML specification treats the quality argument as a hint and leaves the mapping to the implementation, so quality 0.8 is a different file in Chrome, in Firefox and in Safari — a different size, different artefacts, sometimes different chroma subsampling. A page whose main readout is “your file is now 827 bytes” cannot have that number depend on which browser is open. Worse, whether convertToBlob flattens transparency onto black or onto white is also up to the engine, and it is not overridable from outside. So the PNG decoder and the JPEG encoder are both written out, against the specifications listed above, and the only platform API involved is DecompressionStream for the zlib stream inside the PNG — the one part of the job that has a single right answer.

The decoder is the ordinary one: check the signature, walk the chunks, inflate the IDAT stream, then undo the row filters. That last step is the reason a PNG cannot be decoded out of order, because each row is predicted from the row above it and the pixel to its left, and Paeth chooses between three neighbours based on which way the gradient runs. Interlaced files arrive as seven passes of increasing resolution and are reassembled into one image before anything else happens.

Then the flattening, which is the part that matters. Each pixel becomes source × alpha + background × (1 − alpha), computed on the values as stored. Those values are gamma-encoded sRGB, so this is not the physically correct blend; done properly, in linear light, a half-transparent mid-grey over white comes out a few per cent lighter than it does here. It is done this way on purpose, because every browser canvas and every image editor composites in sRGB too, and being right in isolation would mean the JPEG no longer matched the PNG you were just looking at.

The encoder is baseline sequential JPEG. Colours convert to Y, Cb and Cr with the full-range BT.601 coefficients JFIF specifies — the studio-range variant produces a file that looks washed out in every viewer and is invisible in code review. Below quality 90 the two colour planes are averaged down two-to-one in each direction with a box filter rather than point-sampled, because point sampling a red-and-white pattern throws away half the colour and keeps the wrong half. Each 8×8 block goes through the discrete cosine transform, is divided by the Annex K quantisation table scaled for the chosen quality, and is rounded; blocks that overhang the right or bottom edge repeat the last real pixel rather than padding with grey, so the encoder does not spend bits describing an edge that is not in the picture.

Before you read on

You encode the same PNG to JPEG at quality 0.8 through the browser's own canvas, in Chrome, in Firefox and in Safari. What do you get?

• AThe same file three times — 0.8 is a number.

  The HTML specification calls it a hint and leaves the mapping to the implementation.

• BThree different files.

  Yes: different sizes, different artefacts, sometimes different chroma subsampling.

• CThe same image at three sizes — the pixels match, the bytes do not.

  The pixels differ too. Quality decides quantisation, which decides what is thrown away.

Three different files — different sizes, different artefacts, and sometimes different chroma subsampling, because the specification treats the quality argument as a hint rather than a contract. A page whose main readout is your file is now 827 bytes cannot have that number depend on which browser is open. Worse, whether the canvas flattens transparency onto black or onto white is also left to the engine and is not overridable from outside. So the PNG decoder and the JPEG encoder here are both written out against their specifications, and the only platform API involved is DecompressionStream for the zlib stream inside the PNG — the one part of the job with a single right answer.

• Opaque pixels3,07275.0%
• Transparent, filled with the background1,02425.0%

A worked example

A 64 × 64 PNG: a horizontal red-to-blue gradient, with the leftmost sixteen columns fully transparent and storing zeros underneath, which is what an exporter writes. Converted onto a #ffffff background:

Quality 40    766 B
Quality 82    827 B
Quality 95    1.2 KB

Dimensions           64 × 64
Transparent pixels   25.0% of pixels, filled with #ffffff

Those are the readouts as the panel prints them, rounded the way a file manager rounds. The encoder writes 766, 827 and 1,271 bytes exactly, and it is the byte counts the test file asserts, so if the encoder ever changes without this page changing with it, the build fails.

The arithmetic underneath is checked against the specification rather than against another encoder: the quantisation tables at quality 50 must equal the published Annex K tables exactly, the four Huffman tables must be complete prefix-free codes whose symbol sets are precisely the ones a coefficient can need, and no literal 0xFF inside the entropy-coded data may go unstuffed. The decoder is checked the other way round, against pixels — every colour type and bit depth the format allows, all five row filters, and an interlaced file asserted to produce byte-for-byte the same image as the non-interlaced version of itself.

What it does not do

It does not carry colour management across. An ICC profile, a gamma chunk or chromaticity data in the PNG is dropped, and the JPEG is written as plain sRGB, so a wide-gamut photograph will come out looking flatter than the original.

It writes baseline JPEG only, not progressive, so a large file loads top to bottom rather than sharpening in place. It does not verify the CRC on each PNG chunk, so a corrupt file usually surfaces as a decompression failure rather than as a checksum error. It has no way to hit a target file size — you choose a quality and find out what that costs. It does not resize, crop or rotate, and it ignores any EXIF orientation the PNG may carry. Files are capped at 32 MB and 40 megapixels, because both the decoded image and the three colour planes have to be held in memory at once.

And because it does not resize, a large PNG becomes a large JPEG. To resize a photo as well, do that first: fewer pixels compress better than the same pixels compressed harder.