AVIF to JPG: What Happens to Transparent Pixels

When you convert AVIF to JPG, the surprise is almost never the format change. It is the transparent corner that comes back white, black, or a colour nobody asked for. AVIF can carry an alpha channel; JPEG cannot. Something has to be put behind those pixels, and on most converters that decision is made for you — often in a line of code you never see.

The AVIF to JPG converter hands that decision back: a background colour, a custom hex value and a JPG quality, with the same three controls on the site's PNG and WebP converters. Everything below was measured by driving the real page in headless Chrome on a 320 × 240 AVIF whose top-left corner is genuinely transparent, then re-reading the downloaded files from disk with ImageMagick and unzip. Forty browser assertions passed on that run, in 8.1 seconds. None of the figures here come from a specification sheet.

The corner nobody lets you choose

Alpha is not a colour. A transparent pixel in the source AVIF was srgba(0,0,0,0) — red, green and blue all zero, alpha zero. Paint that onto a JPEG canvas without filling behind it first and the zeros survive as black. Fill with white and you get white. Both are legitimate choices; the problem is that the person holding the image rarely gets to make it.

Smallpdf's PNG-to-JPG guide has a troubleshooting heading for exactly this: "My JPG Background Turned White", answered "That's expected if your PNG had transparency. JPG does not support transparent backgrounds." Its FAQ then asks "How do I change the background from transparent to white?" and answers "When you convert PNG to JPG through Smallpdf, transparent areas are automatically filled with a white background since JPG doesn't support transparency." The question is about changing a setting; the answer says there is no setting.

That is the gap this page is about. A logo with a transparent surround placed on a dark slide needs a dark matte, not white. A product cut-out going into a print catalogue needs the printer's paper colour, not black. And an AVIF that was decoded incorrectly can produce a plausible-looking JPG with a blank patch where the image was cut short — a far worse outcome than a clear error.

What the pages that rank actually offer

Four pages, fetched on the day this was written. Their own words:

• Convertio — "All processing for AVIF to JPG happens remotely on Convertio servers, keeping your own hardware free for other tasks." Its drop zone says "1 GB maximum file size or Sign Up", and its FAQ says "Your AVIF files are automatically deleted right after conversion. The resulting JPG files remain available for download for 24 hours, then they are permanently removed." So the input and the output both sit on somebody else's disk, and the output stays there for a day.
• avif2jpg.app — "Files stay on your device. Conversion runs in the browser — nothing is uploaded." It exposes "JPEG quality: 0.92" as the only number, and answers "Does AVIF to JPG work on phones?" with "Yes, on modern mobile browsers that can decode AVIF images." On a browser that cannot decode AVIF, a browser-only converter with no decoder has nothing to work with.
• png2jpg.com — "Converting to JPG automatically fills transparent areas with white, giving you a predictable result for printing or specific use cases." Quality is "an optimized quality setting that balances file size with visual quality", and a batch is "up to 20 PNG images". It does at least say "No upload — Your files never leave your device".
• Smallpdf — "We run your PNG through PDF first, then export it as JPG." Files are uploaded and "we delete files after one hour"; the FAQ suggests "consider upgrading to Pro for unlimited processing power" for batch work.

Two distinct weaknesses, then. Server-side converters make you upload the image and retain the result; client-side converters fix the background and the quality, and quietly assume the browser can decode AVIF at all. Neither of them lets you pick the matte.

Measured: three backgrounds, three different files

The source was a 320 × 240 photographic AVIF, 1,947 bytes, with a 120 × 90 fully transparent rectangle in the top-left corner. Same file, same browser, three settings. The downloaded JPGs were read with magick identify, and the top-left pixel was sampled from the produced file, not from the row label:

All three are 320 × 240 JPEGs with opaque: True, and all three start with the FF D8 JPEG marker rather than a renamed AVIF. The colour you type is the colour in the bytes. That sounds obvious, but it is worth checking: a custom colour field that is not validated would be passed straight to the canvas, and an invalid value silently produces a transparent — therefore black — background. On this run, typing not-a-colour produced no download at all and the row said "Custom background must be a 6-digit hex colour such as #1e3a8a. The JPG was not written, because an invalid colour would flatten transparency to black."

Why 100% quality made a 35,970-byte JPG

The 100% file is 18.5 × the size of the AVIF and nearly ten times the 75% file. Nothing is wrong with it. AVIF is a modern intra-frame codec; JPEG is a 1992 DCT codec that keeps 8 × 8 blocks of coefficients. Re-encoding an already-compressed image at JPEG quality 1.0 spends a lot of bytes faithfully recording compression artefacts. If the reason you are converting is a file-size limit, quality 100 is the wrong end of the slider.

The practical range on that one test image was 3,612 to 35,970 bytes — a 10× spread from one setting, on a file that started at 1,947 bytes. A converter with a single hard-coded 0.92 cannot show you that. On the same panel, a 65,481-byte transparent PNG became a 3,810-byte navy JPG at 85%, and a 1,798-byte WebP became a 4,722-byte custom-colour JPG at 85%. Those two were driven through PNG to JPG and WebP to JPG, which now use the identical controls. Note the direction: the PNG shrank by 94%, the WebP grew by 163%. Converting to JPG is not inherently a size reduction.

When the browser cannot decode AVIF at all

This is the failure the client-side pages do not mention. createImageBitmap() and an <img> element only decode AVIF if the browser ships an AVIF decoder. Older Safari, older Firefox and a long tail of in-app webviews do not. The competitor answer — "Yes, on modern mobile browsers that can decode AVIF images" — quietly excludes them.

The tool ships a WebAssembly libavif decoder as a fallback. To prove it is real rather than a line in an FAQ, the browser run disabled both native decoders in the page and then converted the same AVIF again. Chrome fetched /wasm/avif_dec.wasm with 200 application/wasm (1,170,930 bytes), the row finished, and the downloaded file was a 4,881-byte 320 × 240 JPEG with a white corner. The common path never downloads the decoder; only a browser that needs it does. Animated AVIF is a separate case and is disclosed rather than hidden: the first frame is converted and the row says so.

The awkward files, and the exact messages

A clean conversion proves very little. The same run fed the tool four difficult inputs, and each produced a named refusal instead of a blank screen or a partially blank image:

• An AVIF cut 40 bytes short. AVIF is an ISO-BMFF container: its ftyp, meta and mdat boxes declare their own lengths. Chrome will sometimes decode the boxes that arrived and hand back a partly blank picture. Walking the declared lengths first catches it: "This AVIF is incomplete — it is shorter than its own box headers say it should be, so the file was probably cut short while downloading."
• A JPEG renamed to .avif."This is not an AVIF image — the file does not start with an AVIF ftyp box."
• A corrupt box header (the mdat box declares a length smaller than its own 8-byte header). "This AVIF has a corrupt box header."
• An invalid custom hex. Refused before any file is written, as above, because the alternative is a black background with a confident label on it.

Two files converted together produced a 10,072-byte ZIP holding batch-a.jpg and batch-b.jpg, each 4,927 bytes of real JPEG. The ZIP was unpacked with unzip -p and its first bytes checked, rather than trusting the filename.

How to check the produced JPG yourself

You do not have to take any converter's word for it. Three commands on the file that was downloaded:

1. Ask a second reader what the file actually is. magick identify -format "%m %wx%h %[opaque] %[pixel:p{0,0}]" result.jpg. It should say JPEG 320x240 true and a colour. If it says AVIF, the file was renamed, not converted. If the corner is black and you wanted white, now you know.
2. Check the first two bytes. xxd -l 2 result.jpg should print ffd8. A JPEG that does not start with FF D8 is not a JPEG.
3. Open the batch, not the button label. unzip -Z1 results.zip lists the members; unzip -p results.zip name.jpg | xxd -l 2 checks the bytes inside. A ZIP can be perfectly valid and still hold the wrong files.

If the image is a logo with a transparent surround, sample a pixel from inside that surround rather than the centre of the picture. The centre tells you the photo survived; the corner tells you whether the setting did anything.

Why the file never leaves the tab

Convertio says plainly that "All processing for AVIF to JPG happens remotely on Convertio servers" and that the results stay downloadable for 24 hours. For a product photo that is an inconvenience. For an unreleased design, a client document or a private photo it is the whole problem, and no retention policy fixes it — the copy has already existed somewhere else.

Here the AVIF is read, decoded and re-encoded in the browser tab. The browser run recorded zero POST or PUT requests across every conversion, batch and failure above. There is no upload queue, no per-file cap and no account. The one network fetch in the entire run was the optional decoder wasm, on the browser that needed it — and that is code, not your image.

The short version

JPEG has no alpha channel, so an AVIF to JPG conversion must choose a background. If the converter chooses it for you, black and unchangeable white are the two outcomes; if it fixes the quality, you cannot trade a few kilobytes for a cleaner edge. Choose both, then check the downloaded corner pixel with a second program. And if your browser cannot decode AVIF, a tool that relies only on the browser's decoder will do nothing — ask what happens on that browser before you upload anything to work around it.

If you have a file ready, open the AVIF to JPG converter and set the background before converting. The same panel is on the PNG and WebP converters, so a mixed folder does not need three different habits.