Transparency and flattening

Every conversion on this site passes through one pure planning step before a single pixel is drawn. Given the detected source format and the chosen target, the planner returns a small record: whether transparency must be flattened onto a background colour, which colour, which quality parameter applies (if any), whether only the first frame of an animation survives, and what the output file will be called. This guide covers the first two of those decisions — the ones that permanently change what a picture shows. Every figure below is produced by that same planner at build time on illustrative inputs; nothing is typed in by hand.

What each output format can hold

The engine keeps a capability table for the formats it can produce. Three facts per format: whether the encoded file can carry per-pixel transparency, whether the encoder takes a quality parameter, and the default quality the planner uses when a page passes nothing else. This is the table as the engine holds it:

The transparency column carries the whole subject of this guide: the formats that keep alpha are PNG, WebP and AVIF, and the format that cannot is JPEG. The defaults in the last column are engine constants on the 0–1 scale the planner uses, not recommendations. On the four JPEG converter pages (PNG to JPG, WebP to JPG, HEIC to JPG and AVIF to JPG) the slider starts at 92 because the engine's encoderQualityPercent maps 0.92 onto the 0–100 scale; the AVIF default of 0.5 becomes encoder 50 the same way. The compression lanes do not start from the table: Compress JPEG runs on the MozJPEG lane and its slider starts at that lane's own default, 75 by the same mapping, and Image Compressor has its own starting position. The quality side of the plan has its own guide, quality parameters and compress-to-target.

Which sources can carry transparency

A flatten only matters if there could be something to flatten, so the planner keeps a second list: source formats whose container can hold an alpha channel. The list is not exported, but it can be read off the planner directly by asking, for each format the site decodes, whether a JPEG target would need a flatten. The answer is PNG, WebP, GIF, BMP, HEIC and AVIF. The one decodable format not on the list is JPEG, which has no alpha channel to lose. HEIC and AVIF are on the list because HEIF images can carry an alpha auxiliary plane, and the engine plans the flatten for a JPEG target rather than assume a photo is opaque. Membership is about what the container can hold, never about what a particular file does hold: the planner never looks at pixels.

The rule, and the full matrix

With both lists in hand the decision is one line: a flatten is planned exactly when the target cannot carry alpha and the source is on the alpha-capable list. Here is the planner's answer for every source the site decodes against every target it encodes:

Two things to notice. First, the table is the planner's answer for a format pair, not a list of tool pages: GIF, BMP and HEIC appear only as rows, because the engine lists them as source-only formats and no page offers them as outputs. Second, the only column that ever says "flatten" is JPEG, and the only row that never does is JPEG: compressing a JPEG to a JPEG plans no flatten, because there was never an alpha channel in the source.

The background colour prompt

The methodology page states the policy: when the target cannot represent transparency, the pixels are composited over a background colour first, and the page asks for that colour before converting. Six pages carry the control, placed beside the quality slider and labelled as the background for transparent areas on the converter pages and as the background used if flattening on the compression lanes. Four are converters whose target is JPEG: PNG to JPG , WebP to JPG , HEIC to JPG and AVIF to JPG . Two are the compression lanes, Compress JPEG and Image Compressor , where a non-JPEG input may be re-encoded as JPEG and so may need a flatten. Pages whose targets carry alpha have no such control, because their plans never flatten. Beyond those, Image to PDF embeds every page as JPEG and composites transparency onto #ffffff without a control, as that page states before anyone converts; and Image Resizer writes the format it read, or PNG for the source-only formats (GIF, BMP and HEIC), so no alpha-capable input is ever sent to JPEG and no flatten arises.

The planner validates the colour rather than guessing. Given no colour, the plan carries #ffffff. A six-digit value is kept exactly as given, so a plan built with #1e293b reports #1e293b, and a three-digit form is accepted too: #000 comes back as #000. Those are the lengths the planner takes: of every hex-digit length from one to eight tried at build time, only three and six pass. Anything that is not a hex colour fails the plan before encoding starts; a background of white returns the error Enter the background as a hex color like #ffffff. After converting, the result row notes that transparent areas were flattened and names the colour, so the record of what was done travels with the file.

Worked plans on illustrative files

The filenames below are invented; every other column is the planner's output for that pair, computed when this page was built. "First frame" is the plan's animation flag: the source container can be animated, decoding keeps only its first frame, and the page says so.

A few rows repay a closer look. photo.jpg to JPEG plans flatten no, and because the name would not change, the output takes a -converted suffix so the download cannot shadow the original. receipt.jpg to PNG plans flatten no with quality none (lossless): PNG can carry alpha, but the JPEG source has none to give. loop.gif to PNG keeps alpha yet still raises the first-frame flag (yes), because the two caveats are independent. badge.png to AVIF keeps alpha at the engine's default quality of 0.5, encoder 50, and is encoded by the self-hosted libavif + aom module rather than the browser's canvas encoder. And the planner refuses a quality on a lossless target outright: asking for PNG at quality 0.8 returns This output format is lossless and has no quality setting.

Detected format, not filename

The planner is fed the format the detector found, never the extension. Consider PNG signature bytes saved under the name logo.jpg. The extension check and the plan built from it come back as:

• Actual format: PNG
• Claimed format: JPEG
• Mismatch: yes
• JPEG plan, flatten: yes

The page shows a notice and plans the conversion from the actual format, so the file gets exactly what a PNG source gets, regardless of what the name said. How the detector reaches its verdict is the subject of how image formats are detected.

What flattening does to the pixels, and what it does not

"Composited over a background colour" means the canvas is filled with the chosen colour and the decoded image is drawn on top of it. The result is then handed to the encoder, the browser's own JPEG encoder on the conversion pages or MozJPEG on the Compress JPEG lane, and the encoded bytes carry no record of which pixels used to be transparent. That is why the step is one-way, and why the original should be kept. The reverse direction gains nothing back: the plan for a JPEG source and PNG target has no flatten and no quality, and the PNG it produces is fully opaque.

Flattening is also not the only thing the re-encode changes. Canvas re-encoding strips embedded metadata (EXIF including GPS location, camera model and timestamps, colour-profile tags, and text chunks), with orientation applied during decoding before the metadata is discarded, so the picture stays upright even though the tag does not survive. The details are in what re-encoding does to metadata. Before a download button appears, the produced bytes are sniffed with the same detector used on inputs and the blob is re-decoded to confirm its pixel dimensions match the plan; the whole chain is laid out in the conversion pipeline.

What the tool cannot know

• Whether a file actually contains transparent pixels. The plan is made from the format pair. A flatten is planned for every alpha-capable source headed to JPEG, and the row reports that plan; for an opaque image the compositing step changes nothing.
• Whether the colour suits the destination. The planner checks that the value is a hex colour and records it. It has no idea where the output will be displayed, and it offers no opinion on how the result looks.
• What the alpha used to be. Verification confirms the output's format signature and pixel dimensions. Nothing in the output can be checked against the transparency of the input, because the encoded file no longer holds it.

Common misreadings

• "The converter turned my background white." It composited transparent areas onto the planner's default, #ffffff, because the colour control was left as it was. The control exists so that choice is made before converting.
• "Converting back to PNG will restore the transparency." It will not. The plan for JPEG to PNG flattens nothing because there is nothing to flatten; the output is opaque.
• "The row said 'flattened', so the tool found transparency." The row reports the plan. The planner never inspects pixels; the note means the step ran, and with which colour.
• "A photo has no transparency, so HEIC to JPG should skip the step." HEIF containers can carry an alpha plane, so the engine plans the flatten for the pair and treats it as a no-op when the image is opaque.

Related tools and guides

Targets that keep transparency: WebP to PNG, HEIC to PNG, AVIF to PNG, PNG to WebP or PNG to AVIF. To flatten deliberately, with the colour chosen first: PNG to JPG, WebP to JPG, HEIC to JPG or AVIF to JPG. The other guides in this series are listed at Guides, and the methodology page covers the whole pipeline.

Frequently asked questions

Local processing: flattening, like every other step described here, happens on a canvas in your own browser tab — files are decoded, converted, and verified entirely in your browser and never transmitted. See the methodology page for how to verify the no-upload claim yourself.