También disponible en: English · Português · Français · العربية
Compatibilidad de formatos de imagen en tu navegador
Una prueba en vivo de qué formatos de imagen puede mostrar tu navegador y cuáles puede escribir de verdad, que no son la misma lista.
Por qué una tabla de compatibilidad no puede responder a esto
Las tablas de compatibilidad te dicen qué admite una versión de navegador según una base de datos. Eso es útil y no es la misma pregunta que qué hace el navegador que tienes delante, porque los códecs de imagen son en parte cosa del sistema operativo. La descodificación de HEIC en Safari depende de lo que aporten macOS o iOS, y AVIF llegó en momentos distintos a plataformas distintas con la misma versión de navegador.
La tabla de arriba no es una consulta. Le entrega a tu navegador una imagen real de dos píxeles en cada formato y mira qué pasa, y después le pide a un lienzo que escriba cada formato e inspecciona lo que vuelve. Las dos respuestas son sobre este navegador, en esta máquina, hoy.
Las dos preguntas son de verdad distintas, y esa es justo la parte que casi todas las tablas se dejan fuera.
Cómo leerla
- Mira la primera columna para la compatibilidad al mostrar. Es lo que la gente entiende por admitir un formato: si el navegador puede enseñar una imagen de ese tipo. Se mide descodificando una muestra real, no comprobando un número de versión.
- Mira la segunda columna para la compatibilidad al crear. Si un lienzo puede escribir el formato, que es de lo que depende cualquier conversor, herramienta de captura o editor de imágenes que funcione en el navegador. Suele ser una lista más corta.
- Fíjate en los formatos que salen en una columna y no en la otra. Son los que pillan a la gente: se leen en todas partes y no se escriben en ninguna.
La trampa de la segunda columna
Preguntarle a un lienzo si puede escribir un formato no se puede hacer. No hay ningún método para eso. Lo que sí puedes es pedirle que escriba uno y ver qué te da, y la especificación es explícita sobre lo que pasa cuando la respuesta es no: el tipo de salida por defecto es image/png, y ese mismo tipo se usa cuando el pedido no está admitido.
Así que una llamada pidiendo AVIF en un navegador sin codificación AVIF no lanza ningún error, no devuelve null y no activa ninguna señal: devuelve un PNG. Nada en el resultado dice que ha habido una sustitución salvo el tipo del propio blob, y por eso la única forma honesta de construir esta columna es codificar algo y volver a leer ese tipo.
No es una curiosidad. Es la razón de que un conversor que funciona en el navegador pueda entregarte un archivo llamado foto.avif que en realidad es un PNG, más grande que el original, con la extensión equivocada y sin ningún error por ninguna parte. Si escribes código que llama a toBlob con algo que no sea image/png, compara el tipo que recibes con el que pediste. Es una línea y es la diferencia entre un conversor que funciona y uno que miente en silencio.
La dirección contraria no tiene ese problema. Descodificar falla a gritos: dale al navegador bytes que no sepa leer y la descodificación se rechaza. Esa asimetría, una dirección detectable y la otra silenciosa, es toda la razón de que esta página tenga dos columnas en vez de una.
Límites honestos
Se prueban ocho formatos, y solo se pregunta por la creación de cuatro: PNG, JPEG, WebP y AVIF. Un lienzo nunca ha escrito GIF, BMP, TIFF ni ICO, así que probarlos daría el recurso al PNG y haría parecer deficiente a un navegador por no hacer algo que ningún navegador ha hecho jamás. Esos cuatro lo dicen en la segunda columna en vez de mostrar un falso negativo.
Las muestras son de dos píxeles de lado y son archivos reales producidos por un codificador de verdad, releídos después para comprobar que son el formato y el tamaño que dicen ser. Eso importa más de lo que parece: un base64 escrito a mano que estuviera sutilmente mal formado haría parecer que un navegador no admite un formato que admite perfectamente. La muestra de ICO es de dieciséis píxeles porque el codificador usado genera un fragmento inservible por debajo de ese tamaño, algo que la comprobación detectó en vez de dejarlo pasar.
Un no en la descodificación puede significar que al navegador le falta el códec o que ha rechazado ese archivo en concreto, y la prueba no puede distinguirlo desde fuera. Para una imagen válida de dos píxeles lo primero es abrumadoramente más probable, pero es un sondeo y no una demostración.
HEIC y JPEG XL no están en la tabla. El codificador disponible cuando se generaron estas muestras no podía producir ninguno de los dos, y publicar una muestra montada a mano habría dejado sin sentido cualquier resultado negativo. Una fila ausente es más honesta que una fila en la que no se puede confiar.
¿Por qué es gratis?
Todo lo de aquí ocurre en tu navegador: unos pocos kilobytes de imágenes de muestra, un lienzo de dos píxeles y ninguna petición de red una vez cargada la página. No hay coste de servidor que recuperar ni cuenta que crear.
No se sube nada, porque no hay nada que subir. La prueba no lee ningún archivo tuyo: usa sus propias muestras y su propio lienzo.