LeanImg

PNG vs JPG: ¿cuál deberías guardar realmente?

Sin pérdida versus con pérdida, el canal alfa que JPG no tiene y la submuestreo de croma que difumina el texto, con tamaños de archivo medidos de ambos formatos.

PNG y JPG difieren en una pregunta: ¿recuerda el archivo cada píxel exactamente? PNG lo hace. JPG descarta detalles que la visión humana es débil para captar, y a cambio se vuelve mucho más pequeño. Esa única división decide casi cada caso que encontrarás, y se presenta de una manera para una foto de playa y de otra para una captura de pantalla de una hoja de cálculo.

Cada número a continuación proviene de las propias herramientas de LeanImg ejecutándose en una pestaña del navegador, en dos archivos de prueba: texture.jpg a 3840x2160 y 538.6 KB, más alpha.png a 900x606 y 942.4 KB con un fondo transparente. Construimos estas herramientas sin rutas de API y sin acciones de servidor, por lo que el archivo nunca sale de tu máquina. La mayoría de los sitios en esta categoría suben tu imagen a un servidor y luego prometen eliminarla una hora después. No hay nada aquí que eliminar, por eso nuestra página de privacidad es breve.

¿Cuál debería elegir, PNG o JPG?

Las fotos van a JPG. Las capturas de pantalla, logotipos, gráficos, arte lineal y cualquier cosa que necesite transparencia van a PNG. La guía de formatos de MDN traza la misma línea. En modo inteligente, nuestro compresor llevó texture.jpg de 538.6 KB a 286.1 KB con MozJPEG a calidad 80, una reducción del 47%. Arrastra el control deslizante a 60 y la misma foto queda en 212.4 KB. A 30 son 131 KB, una reducción del 76%.

Esa división proviene de cómo cada formato comprime. El diseño de JPG asume que los píxeles vecinos se mezclan entre sí, lo que se adapta a los degradados y al grano de película. Una captura de pantalla rompe esa suposición en cada borde de texto. PNG predice cada píxel a partir de sus vecinos y luego desinfla la diferencia, por lo que hace su mejor trabajo en las tiras planas de color idéntico de las que está hecha una interfaz de usuario.

¿Qué hace realmente la compresión sin pérdida al tamaño del archivo?

Sin pérdida significa que los píxeles decodificados regresan bit por bit idénticos, lo que requiere la especificación PNG. No significa que el archivo no pueda reducirse. El modo PNG de nuestro compresor ejecuta oxipng en el nivel 3, y llevó alpha.png de 942.4 KB a 383.9 KB. Eso es un 59% menos con cada valor de píxel preservado.

La opción de PNG "tamaño de archivo más pequeño" es un animal diferente. Ejecuta imagequant, que reduce la imagen a una paleta de colores antes de que se escriba el PNG, y alpha.png salió a 98.3 KB. Eso es un 90% menos. Es un resultado con pérdida sin importar lo que implique la extensión .png, así que conserva el original si esa imagen es una copia maestra.

Tarjeta de resultado del compresor de LeanImg mostrando alpha.png reducido de 942.4 KB a 98.3 KB utilizando el modo de paleta
alpha.png a 900x606, cuantizado a una paleta: 942.4 KB reducido a 98.3 KB, una reducción del 90%.

¿Por qué difumina JPG el texto de color y las líneas delgadas?

Porque JPG almacena el color a una resolución más baja que el brillo. El formato mantiene la luma separada de los dos canales de croma, como se especifica en ITU-T T.81, y los codificadores normalmente submuestrean el croma para que una muestra de color cubra un bloque de píxeles de 2x2. En una foto de 3840x2160 como texture.jpg no lo notarás. En una línea roja de un píxel contra blanco, el color de esa línea se promedia con tres vecinos blancos antes de que se aplique cualquier configuración de calidad, y ninguna posición del control deslizante lo recupera.

Las capturas de pantalla son donde muerde. Cambiar a WebP no lo evita, porque el modo con pérdida de WebP está bloqueado a croma 4:2:0 y aplica el mismo promedio. PNG mantiene el valor RGB exacto de cada píxel, por lo que las capturas de interfaz de usuario, los códigos QR y las superposiciones de texto pertenecen allí. Si el PNG sigue siendo demasiado pesado, cuantízalo y conserva el formato.

¿Qué pasa con la transparencia cuando guardo como JPG?

Se llena. JPEG no lleva ningún canal alfa en ningún modo, así que algo tiene que decidir qué hay detrás de tus píxeles transparentes. Nuestro convertidor de PNG a JPG los compone sobre blanco antes de codificar, y el compresor hace lo mismo siempre que el formato de destino no tenga alfa. Sin ese paso, saldrían negros, porque un píxel completamente transparente generalmente lleva RGB 0,0,0 debajo.

No puedes revertir ese viaje de ida y vuelta. Volver a través de JPG a PNG te entrega un PNG con un rectángulo blanco donde solía estar la transparencia, más cualquier artefacto JPG que la primera pasada haya incorporado. La compresión también elimina cada pieza de metadatos: EXIF, GPS, perfil ICC y miniatura incrustada se van, aunque la orientación sobrevive. Conserva el PNG maestro; lo necesitarás. Si estás recortando un sujeto de una foto, nuestro eliminador de fondo siempre escribe PNG con alfa por esta razón, que también es por qué un recorte regresa más pesado que el JPG que ingresaste, y el generador de iconos establece por defecto su color de fondo en #ffffff, así que un logotipo transparente aterriza en un cuadrado blanco hasta que cambies ese campo.

¿Por qué es mi PNG mucho más grande que el JPG?

El ruido fotográfico no le da nada al predictor de PNG con qué trabajar. Cada fila se adivina a partir de la fila anterior y la diferencia restante se desinfla, lo que es excelente en un botón plano y casi inútil en grano. Mira los dos archivos de prueba. alpha.png es 900x606 y llegó a 942.4 KB, mientras que texture.jpg es 3840x2160, más de quince veces el conteo de píxeles, y llegó a 538.6 KB. La cuantización de paleta es la palanca que cierra esa brecha, y llevó alpha.png a 98.3 KB.

¿Debería guardar WebP o AVIF y saltarme la pregunta?

A veces, aunque vale la pena medir. Ejecutamos texture.jpg a través del compresor en la misma posición del control deslizante de 80 para los tres formatos, luego nuevamente a 63.

Misma fuente ambas veces: texture.jpg, 3840x2160, 538.6 KB.
Formato de salidaControl deslizante 80Control deslizante 63Tiempo de codificación
JPEG (MozJPEG)286.1 KBno medidoinstantáneo
WebP290.3 KB200.6 KBinstantáneo
AVIF312.7 KB186.9 KB10 a 11 segundos

AVIF produciendo el archivo más grande en el control deslizante 80 parece contradictorio, y la causa radica en nuestro propio código. Para una fuente JPEG, el compresor multiplica tu control deslizante por la calidad que lee de las tablas de cuantización de la fuente, por lo que una fuente estimada en 60 con el control deslizante en 80 en realidad codifica a 48. WebP y AVIF toman 80 al pie de la letra. A 63, que es el valor predeterminado en modo inteligente para AVIF, el orden se invierte: AVIF es 186.9 KB y WebP es 200.6 KB frente a esa fuente de 538.6 KB. AVIF también costó de 10 a 11 segundos por codificación donde JPEG y WebP terminaron instantáneamente, y vale la pena verificar el soporte del navegador antes de comprometerte. Desglosamos esa comparación en profundidad en el artículo sobre si WebP realmente supera a JPG.

¿Qué debería hacer con el archivo frente a mí?

Abre el compresor. Ejecuta tu archivo dos veces. Si es una foto, toma primero el modo inteligente, luego mueve el control deslizante a 60 y compara las dos salidas a zoom completo. Si tiene texto o transparencia, mantente en PNG y prueba ambos modos PNG: sin pérdida llevó alpha.png a 383.9 KB y el modo de paleta lo llevó a 98.3 KB. Redimensiona primero cuando la imagen esté destinada a una columna de 800px, ya que el redimensionador escribe PNG sin pérdida y re-codifica todo lo demás a calidad 90 por defecto. Y si el destino es un documento, un JPG aterriza en una página PDF re-codificada una vez más a calidad 92, que es una generación extra a la que planear.