La compresión JPEG, PNG y WebP no es el mismo problema
La estrategia adecuada depende del formato y de la propiedad que deba conservarse. JPEG suele intercambiar fidelidad por menor tamaño, PNG puede optimizarse sin cambiar los píxeles y WebP puede contener datos con o sin pérdidas según el origen y el codificador.
Última revisión técnica: 2026-09-19
Puntos clave
- Una imagen más pequeña no es automáticamente equivalente a la original.
- Dimensiones, transparencia alfa, formato y metadatos son propiedades distintas que necesitan decisiones explícitas.
- La recodificación suele eliminar metadatos originales incluso cuando se conservan anchura y altura.
- Un compresor verificado debe decodificar o inspeccionar su propia salida antes de ofrecerla.
JPEG: recompresión con pérdidas y límites
JPEG está diseñado para imágenes fotográficas y normalmente usa compresión con pérdidas. Recodificar con una calidad menor puede ahorrar bytes manteniendo las mismas dimensiones, pero se descarta parte de la información visual.
Las recompresiones repetidas pueden acumular artefactos, por lo que un compresor debe usar una estrategia de calidad acotada y detenerse en lugar de degradar indefinidamente.
PNG: píxeles sin pérdidas y decisiones estructurales
PNG admite datos de imagen sin pérdidas y transparencia alfa. Un optimizador puede reorganizar scanlines o elegir filtros más eficientes sin cambiar los valores de píxel decodificados.
No todas las variantes PNG son igual de sencillas. Paletas, entrelazado, profundidades de bits altas y chunks poco comunes pueden requerir un tratamiento separado.
WebP: importan el soporte y el comportamiento del codificador
WebP admite varios modos de codificación, incluida transparencia. El codificador del navegador puede tratar los metadatos de forma distinta al origen y no implica que se conserven todas las funciones posibles de WebP.
Un compresor enfocado debe definir variantes de entrada compatibles, preservar dimensiones y comportamiento alfa exigidos y confirmar que la salida sea realmente WebP.
Cómo separa ZAMAZY las herramientas
ZAMAZY utiliza compresores separados para JPEG, PNG y WebP en vez de un único botón genérico. Cada herramienta tiene sus propias reglas de soporte y verificación.
JPEG acepta explícitamente recompresión con pérdidas, PNG prioriza la preservación sin pérdidas de píxeles y WebP se verifica como WebP con las dimensiones y transparencia esperadas dentro del subconjunto compatible.
Ejemplo y ayuda para decidir
Una fotografía, una captura con texto pequeño y un logotipo transparente tienen prioridades diferentes. JPEG puede servir para fotografías cuando se acepta cierta pérdida; PNG sin pérdidas es útil cuando importan los píxeles decodificados exactos y el alfa. WebP admite varios modos, pero el compresor WebP de ZAMAZY usa una recodificación con pérdidas acotada, no todos los modos que permite el formato.
Elige el compresor que corresponda al formato existente. Estas herramientas enfocadas no son conversores de formato ni redimensionadores. Compara bordes de texto, gradientes, color y límites transparentes en el resultado. Mantener anchura y altura no demuestra que los píxeles RGB sean idénticos. Un valor de calidad es un ajuste del codificador, no una puntuación visual universal ni un porcentaje portable entre navegadores.
Cuándo este enfoque no es adecuado
Conservar alfa no demuestra conservar perfiles de color, animación ni todos los metadatos. Una entrada ya bien comprimida puede no producir un resultado menor aceptable. Si necesitas píxeles exactos, animación, un flujo de color de impresión o un formato nuevo específico, no sustituyas esa necesidad por compresión con pérdidas solo porque la extensión sea compatible.
Ejemplo editorial, no un benchmark. Complemento revisado el:
Fuentes y límites de la evidencia
Estas fuentes explican formatos y métodos. No certifican a ZAMAZY; los hechos y límites compatibles de ZAMAZY se indican en la página de cada herramienta.
- MDN: Image file type and format guide — Compromisos entre formatos; las capacidades de un formato no implican soporte de la herramienta.
- W3C: PNG Specification, Third Edition — Píxeles PNG, alfa y chunks; no implica que se acepte cualquier variante PNG.
- Google: WebP Container Specification — Modos WebP, alfa, animación y contenedores de metadatos.
- MDN: HTMLCanvasElement.toBlob() — Formato de codificación y parámetros de calidad; no es una afirmación certificada de eliminación de metadatos.
Estudio propio del fabricante: preservación PNG sin pérdidas
Estado: verificado. ZAMAZY procesó tres archivos PNG fijos y totalmente sintéticos con la engine PNG sin cambios, y después volvió a decodificar y comparar estructuralmente cada resultado.
Este es un estudio propio del fabricante, no una certificación independiente. Las entradas, deliberadamente fáciles de comprimir, se crearon con nivel 0 de compresión zlib y por eso no representan un benchmark típico de compresión.
| Fixture | Dimensiones | Entrada | Salida | Preservación verificada |
|---|---|---|---|---|
rgb-flat-v1 | 256 × 64 | 49.284 B | 252 B | Scanlines idénticas; chunks no-IDAT idénticos; segunda pasada rechazada cuando no produjo una salida menor |
rgba-pattern-v1 | 64 × 32 | 8292 B | 4700 B | Scanlines idénticas; chunks no-IDAT idénticos; alfa idéntico; segunda pasada rechazada cuando no produjo una salida menor |
gray-metadata-v1 | 64 × 32 | 2199 B | 158 B | Scanlines idénticas; chunks no-IDAT idénticos; segunda pasada rechazada cuando no produjo una salida menor |
Casos negativos
En el entorno verificado se rechazaron datos zlib truncados, una suma Adler-32 no válida y datos adicionales después del stream zlib.
truncated-zlib: rechazadoinvalid-adler32: rechazadotrailing-zlib-data: rechazado
Método y límites
El estudio comparó scanlines decodificadas, geometría y todos los chunks no-IDAT antes y después de la optimización; en el caso RGBA se comprobó expresamente el alfa. La descompresión de control separada usó Node zlib y no es un verificador externo independiente.
La evidencia se aplica solo a las fixtures documentadas y a la versión indicada de la engine. No demuestra todas las variantes PNG, comportamiento de red del navegador, compatibilidad de dispositivos, tasas típicas de compresión ni seguridad para archivos arbitrarios de usuarios.
Estudio png-preservation-v1 · revisado el · Node 22.22.3 / zlib 1.3.1-e00f703 / linux x64 ·commit de la engine a12415a3a19f
Preguntas frecuentes
¿PNG es siempre más grande que JPEG?
No. Depende de la imagen. Las fotografías suelen favorecer JPEG, mientras que gráficos planos, imágenes con texto y transparencia pueden favorecer PNG.
¿Mantener las mismas dimensiones significa que la imagen es sin pérdidas?
No. Anchura y altura pueden mantenerse mientras JPEG o WebP con pérdidas descarta información visual durante la codificación.
¿Por qué pueden desaparecer metadatos después de comprimir?
La recodificación del navegador suele crear un stream nuevo en vez de copiar el contenedor original. EXIF, GPS y otros metadatos necesitan soporte explícito para conservarse.