Prise en charge des formats d'image par votre navigateur

Pourquoi un tableau de compatibilité ne répond pas à la question

Les tableaux de compatibilité indiquent ce qu'une version de navigateur prend en charge d'après une base de données. C'est utile, et ce n'est pas la même question que ce que fait le navigateur devant vous, car les codecs d'image relèvent en partie du système d'exploitation. Le décodage HEIC dans Safari dépend de ce que fournissent macOS ou iOS, et l'AVIF est arrivé à des moments différents selon les plateformes pour une même version de navigateur.

Le tableau ci-dessus n'est pas une consultation de base. Il remet à votre navigateur une véritable image de deux pixels dans chaque format et observe ce qui se produit, puis demande à un canvas d'écrire chaque format et inspecte ce qui revient. Les deux réponses concernent ce navigateur, sur cette machine, aujourd'hui.

Les deux questions sont réellement distinctes, et c'est précisément la partie que la plupart des tableaux passent sous silence.

Comment le lire

1. Regardez la première colonne pour l'affichage. C'est ce que l'on entend d'ordinaire par prise en charge d'un format : le navigateur sait-il montrer une image de ce type. La réponse est mesurée en décodant un échantillon réel, pas en consultant un numéro de version.
2. Regardez la seconde colonne pour la création. La capacité d'un canvas à écrire le format, dont dépendent tous les convertisseurs, outils de capture et éditeurs d'images qui fonctionnent dans le navigateur. La liste est souvent plus courte.
3. Repérez les formats présents dans une colonne et absents de l'autre. Ce sont eux qui piègent : lisibles partout, inscriptibles nulle part.

Le piège de la seconde colonne

Demander à un canvas s'il sait écrire un format est impossible : aucune méthode ne le permet. Ce que l'on peut faire, c'est lui demander d'en écrire un et regarder ce qu'on obtient — et la spécification est explicite sur ce qui se passe quand la réponse est non : le type de sortie par défaut est image/png, et ce même type sert lorsque le type demandé n'est pas pris en charge.

Ainsi, un appel demandant de l'AVIF sur un navigateur dépourvu d'encodage AVIF ne lève aucune erreur, ne renvoie pas null et n'active aucun indicateur : il renvoie un PNG. Rien dans le résultat ne signale la substitution, hormis le type du blob lui-même, et c'est pourquoi la seule façon honnête de construire cette colonne est d'encoder quelque chose puis de relire ce type.

Ce n'est pas une curiosité. C'est la raison pour laquelle un convertisseur fonctionnant dans le navigateur peut vous remettre un fichier nommé photo.avif qui est en réalité un PNG : plus lourd que l'original, avec la mauvaise extension, et sans la moindre erreur. Si vous écrivez du code appelant toBlob avec autre chose qu'image/png, comparez le type reçu au type demandé. C'est une ligne, et c'est la différence entre un convertisseur qui fonctionne et un convertisseur qui ment en silence.

Le sens inverse ne pose pas ce problème. Le décodage échoue bruyamment : donnez au navigateur des octets qu'il ne sait pas lire et le décodage est rejeté. Cette asymétrie — un sens détectable, l'autre silencieux — justifie à elle seule que cette page comporte deux colonnes plutôt qu'une.

Limites assumées

Huit formats sont testés, et quatre seulement sont interrogés sur la création : PNG, JPEG, WebP et AVIF. Un canvas n'a jamais écrit de GIF, de BMP, de TIFF ni d'ICO ; les sonder reviendrait à signaler le repli sur le PNG et à faire passer un navigateur pour déficient parce qu'il ne fait pas une chose qu'aucun navigateur n'a jamais faite. Ces quatre formats le disent dans la seconde colonne plutôt que d'afficher un faux négatif.

Les échantillons mesurent deux pixels de côté et sont de vrais fichiers produits par un encodeur réel, puis relus pour vérifier qu'ils sont bien du format et de la taille annoncés. Cela compte plus qu'il n'y paraît : un base64 saisi à la main et subtilement mal formé ferait croire qu'un navigateur ne gère pas un format qu'il gère parfaitement. L'échantillon ICO fait seize pixels, car l'encodeur employé produit en dessous une ébauche inutilisable — ce que la vérification a détecté au lieu de le laisser passer.

Un non au décodage peut signifier que le navigateur n'a pas le codec, ou qu'il a refusé ce fichier précis, et le test ne peut pas les distinguer de l'extérieur. Pour une image valide de deux pixels, la première explication est de loin la plus probable, mais il s'agit d'un sondage et non d'une preuve.

Le HEIC et le JPEG XL ne figurent pas au tableau. L'encodeur disponible lors de la génération de ces échantillons ne produisait ni l'un ni l'autre, et publier un échantillon assemblé à la main aurait vidé de son sens tout résultat négatif. Une ligne absente est plus honnête qu'une ligne à laquelle on ne peut pas se fier.

Pourquoi est-ce gratuit ?

Tout se passe ici dans votre navigateur : quelques kilo-octets d'images d'échantillon, un canvas de deux pixels, et aucune requête réseau une fois la page chargée. Il n'y a aucun coût serveur à récupérer ni compte à créer.

Rien n'est envoyé, puisqu'il n'y a rien à envoyer. Le test ne lit aucun de vos fichiers : il utilise ses propres échantillons et son propre canvas.