Image format support in your browser

Why a support table cannot answer this

Compatibility tables tell you what a browser version supports according to a database. That is useful and it is not the same question as what the browser in front of you does, because image codecs are partly an operating system matter. HEIC decoding on Safari depends on what macOS or iOS provides, and AVIF arrived at different times on different platforms for the same browser version.

The table above is not a lookup. It hands your browser a real two-pixel image in each format and sees what happens, then asks a canvas to write each format and inspects what comes back. Both answers are about this browser, on this machine, today.

The two questions are genuinely different, and that is the part most tables leave out entirely.

How to read it

1. Look at the first column for display support. This is the one people mean by format support: can the browser show an image of this type. It is measured by decoding a real sample, not by checking a version number.
2. Look at the second column for creation support. Whether a canvas can write the format — which is what any in-browser converter, screenshot tool or image editor depends on. It is often a shorter list.
3. Note the formats that appear in one column and not the other. Those are the ones that catch people out: readable everywhere, writable nowhere.

The trap in the second column

Asking a canvas whether it can write a format is not possible. There is no method for it. What you can do is ask it to write one and see what you get, and the specification is explicit about what happens when the answer is no: the default output type is image/png, and that same type is used when the requested one is not supported.

So a call asking for AVIF on a browser without AVIF encoding does not throw, does not return null, and does not set any flag. It returns a PNG. Nothing in the result says a substitution happened except the type of the blob itself, which is why the only honest way to build this column is to encode something and read that type back.

This is not a curiosity. It is why an in-browser converter can hand you a file named photo.avif that is really a PNG — larger than the original, with the wrong extension, and no error anywhere. If you write code that calls toBlob with anything other than image/png, compare the type you get against the type you asked for. It is one line and it is the difference between a converter that works and one that silently lies.

The reverse direction has no such problem. Decoding fails loudly: hand the browser bytes it cannot read and the decode rejects. That asymmetry — one direction detectable, the other silent — is the whole reason this page has two columns rather than one.

Honest limits

Eight formats are tested, and only four are asked about creation: PNG, JPEG, WebP and AVIF. A canvas has never written GIF, BMP, TIFF or ICO, so probing them would report the PNG fallback and make a browser look deficient for not doing something no browser has ever done. Those four say so in the second column rather than showing a false negative.

The samples are two pixels square and are real files produced by an actual encoder, then read back and checked to be the format and size they claim. That matters more than it sounds: a hand-typed base64 blob that is subtly malformed would make a browser look like it lacks a format it supports perfectly well. The ICO sample is sixteen pixels square because the encoder used produces an unusable stub below that size, which the check caught rather than shipping.

A decode result of no can mean the browser lacks the codec or that it declined this particular file, and the test cannot tell those apart from the outside. For a two-pixel valid image the first is overwhelmingly likely, but it is a probe rather than a proof.

HEIC and JPEG XL are not in the table. Neither could be produced by the encoder available when these samples were generated, and shipping a sample that had been assembled by hand would have made any negative result meaningless. An absent row is more honest than an untrustworthy one.

Why is it free?

Everything here happens in your browser: a few kilobytes of sample images, one two-pixel canvas, and no network requests once the page has loaded. There is no server cost to recover and no account to create.

Nothing is uploaded, because there is nothing to upload. The test does not read any file of yours; it uses its own samples and its own canvas.