Suporte a formatos de imagem no seu navegador

Por que uma tabela de compatibilidade não responde a isto

Tabelas de compatibilidade dizem o que uma versão de navegador suporta segundo um banco de dados. Isso é útil e não é a mesma pergunta que o que o navegador à sua frente faz, porque codecs de imagem são em parte assunto do sistema operacional. A decodificação de HEIC no Safari depende do que o macOS ou o iOS fornece, e o AVIF chegou em momentos diferentes em plataformas diferentes na mesma versão de navegador.

A tabela acima não é uma consulta. Ela entrega ao seu navegador uma imagem real de dois pixels em cada formato e observa o que acontece, depois pede a um canvas que escreva cada formato e inspeciona o que volta. As duas respostas são sobre este navegador, nesta máquina, hoje.

As duas perguntas são genuinamente diferentes, e é justamente essa parte que quase toda tabela deixa de fora.

Como ler

1. Veja a primeira coluna para o suporte a exibir. É o que as pessoas querem dizer com suportar um formato: se o navegador consegue mostrar uma imagem desse tipo. É medido decodificando uma amostra real, não conferindo um número de versão.
2. Veja a segunda coluna para o suporte a criar. Se um canvas consegue escrever o formato — do que depende qualquer conversor, ferramenta de captura ou editor de imagens que rode no navegador. Costuma ser uma lista mais curta.
3. Repare nos formatos que aparecem numa coluna e não na outra. São os que pegam as pessoas de surpresa: legíveis em todo lugar, graváveis em lugar nenhum.

A armadilha da segunda coluna

Perguntar a um canvas se ele consegue escrever um formato não é possível. Não existe método para isso. O que dá para fazer é pedir que ele escreva um e ver o que você recebe, e a especificação é explícita sobre o que acontece quando a resposta é não: o tipo de saída padrão é image/png, e esse mesmo tipo é usado quando o pedido não tem suporte.

Então uma chamada pedindo AVIF num navegador sem codificação AVIF não lança erro, não devolve null e não levanta bandeira nenhuma: devolve um PNG. Nada no resultado diz que houve substituição, a não ser o tipo do próprio blob, e é por isso que a única forma honesta de montar esta coluna é codificar algo e ler esse tipo de volta.

Não é curiosidade. É a razão de um conversor que roda no navegador poder te entregar um arquivo chamado foto.avif que na verdade é um PNG — maior que o original, com a extensão errada e sem erro algum em lugar nenhum. Se você escreve código que chama toBlob com algo que não seja image/png, compare o tipo recebido com o que pediu. É uma linha e é a diferença entre um conversor que funciona e um que mente em silêncio.

A direção contrária não tem esse problema. Decodificar falha alto: entregue ao navegador bytes que ele não sabe ler e a decodificação é rejeitada. Essa assimetria — uma direção detectável, a outra silenciosa — é toda a razão de esta página ter duas colunas em vez de uma.

Limites honestos

Oito formatos são testados, e só quatro são perguntados sobre criação: PNG, JPEG, WebP e AVIF. Um canvas nunca escreveu GIF, BMP, TIFF ou ICO, então testá-los reportaria o recurso ao PNG e faria um navegador parecer deficiente por não fazer algo que nenhum navegador jamais fez. Esses quatro dizem isso na segunda coluna em vez de mostrar um falso negativo.

As amostras têm dois pixels de lado e são arquivos reais produzidos por um codificador de verdade, relidos depois para conferir que são o formato e o tamanho que afirmam. Isso importa mais do que parece: um base64 digitado à mão e sutilmente malformado faria um navegador parecer não suportar um formato que ele suporta perfeitamente. A amostra de ICO tem dezesseis pixels porque o codificador usado gera um fragmento inútil abaixo desse tamanho, o que a checagem pegou em vez de deixar passar.

Um não na decodificação pode significar que falta o codec ao navegador ou que ele recusou aquele arquivo específico, e o teste não distingue os dois de fora. Para uma imagem válida de dois pixels o primeiro é esmagadoramente mais provável, mas isto é uma sondagem, não uma prova.

HEIC e JPEG XL não estão na tabela. O codificador disponível quando estas amostras foram geradas não produzia nenhum dos dois, e publicar uma amostra montada à mão teria tornado qualquer resultado negativo sem sentido. Uma linha ausente é mais honesta do que uma linha em que não se pode confiar.

Por que é grátis?

Tudo aqui acontece no seu navegador: alguns kilobytes de imagens de amostra, um canvas de dois pixels e nenhuma requisição de rede depois que a página carrega. Não há custo de servidor a recuperar nem cadastro a fazer.

Nada é enviado, porque não há o que enviar. O teste não lê nenhum arquivo seu: usa as próprias amostras e o próprio canvas.