Why Transparent Images Turn Black When Converted to JPG
If you've ever converted a logo or icon with a transparent PNG or AVIF background into a JPG and watched the previously-transparent area come out solid black, you're not alone. It looks like a bug, but it's actually a trap that any image converter can fall into — the result of a fundamental limitation baked into the JPG format itself, combined with a default behavior of the Canvas API.
1. JPG has no concept of transparency to begin with
PNG, WebP, and AVIF can all store an alpha (A, transparency) value per pixel in addition to the RGB (red, green, blue) values. JPG (JPEG), on the other hand, was designed in the 1990s specifically for compressing photographs, so it simply has no slot for an alpha channel. That means the moment you save a source image with transparent pixels as a JPG, the alpha information has to be discarded somewhere, and a real, concrete color has to be chosen to take its place. The problem arises when the converter doesn't explicitly decide "what color should fill in instead."
2. Why specifically black: Canvas's default value
Browser-based image format converters typically work by drawing the source image onto a <canvas> element, then re-encoding that canvas into the target format. When a new canvas is created, every pixel on it is initialized by default to RGBA(0,0,0,0) — in other words, fully transparent black. If you draw a transparent PNG straight onto this canvas, the transparent areas stay at alpha 0, and if you then encode straight to JPG, the encoder drops the alpha value and leaves only RGB(0,0,0) — pure black. The key point isn't "it's invisible because it's transparent" — it's that "the default background color behind that transparency was black all along."
3. The alpha compositing formula behind it
The final color rendered on screen follows the alpha compositing formula: "source color × alpha + background color × (1 − alpha)." Comparing how a semi-transparent pixel looks differently depending on whether the background is black (0,0,0) or white (255,255,255) makes this concrete:
| Original pixel (RGBA) | Composited over black background | Composited over white background |
|---|---|---|
| Red, 50% alpha (255,0,0,0.5) | (128,0,0) dark red | (255,128,128) light pink |
| Fully transparent (0,0,0,0) | (0,0,0) black | (255,255,255) white |
The second row of that table is the heart of the problem. A fully transparent pixel technically means "there is no color there," but once the alpha is dropped, what it becomes — black or white — depends entirely on what background it was composited over. If you leave a canvas unfilled, the result is identical to compositing over a black background.
4. How this tool actually prevents it
Checking the source code of the AVIF to JPG Converter directly, there's logic that fills the entire canvas white with ctx.fillStyle='#ffffff' before drawing the source image, but only when the target format is JPG. That way, previously-transparent areas end up filled with white instead of black, which produces a natural-looking result for images like logos or icons that are typically used on a white background. Conversely, when saving to a format that supports an alpha channel — PNG or WebP — this white-fill step is skipped and transparency is preserved as-is. Branching on the target format is the key piece of logic here.
5. Not every converter handles this the same way
This white-fill step is not standard behavior — it's an exception a converter has to explicitly implement. Converters or image-editing software that lack this logic, or their default export options, can save transparent areas as black instead, so when using a different tool it's worth getting into the habit of checking the background color in the preview first. If your source is a PNG, it's also worth confirming that the same principle applies in the PNG to JPG Converter.
6. If you need a background color other than white
For situations like product detail pages where the background needs to match a specific brand color, the automatic white fill can actually get in the way. In that case, it's better to first composite the color you actually want using the Transparent Background Maker and then convert to JPG, or to keep working in a format that preserves transparency — PNG or WebP via the WebP to JPG Converter flow — finish compositing against whatever background you need, and only export to JPG as the very last step.
Frequently Asked Questions
Q. Does the same problem happen when converting PNG to JPG too?
Yes. Whether the source is AVIF, PNG, or WebP, if the source has an alpha channel and the target format is JPG, the same underlying mechanism can produce a black background. This happens with any "alpha-capable source → alpha-less target format" combination, regardless of the specific formats involved.
Q. Can a file that already came out black be recovered afterward?
No. Once a file has been saved as JPG, the alpha information itself is already gone, so recovery is impossible. You have to re-convert starting from a source that still has its alpha channel intact — PNG, WebP, or AVIF.
Q. Why fill with white and not black?
Because most transparent-background images in real use — logos, icons, scanned documents — end up placed on a white background, white is simply the safest default choice. If you need a different color, you have to composite it yourself before converting.
Q. Does my file get uploaded to a server?
No. The entire process — decoding via an img tag, drawing onto a Canvas, and re-encoding — runs inside your browser, so the original file is never sent anywhere externally.