¿Tu imagen comprimida pesa más? Las 3 causas reales

Lo más probable es que tu compresor esté bien. Cuando la compresión de imágenes no funciona, es decir, cuando el resultado vuelve con el mismo tamaño o bastante más grande que lo que cargaste, la causa casi siempre es una de estas tres. Que la herramienta esté rota no figura entre ellas.

Primero la más común. Cualquier herramienta que comprima a través del elemento canvas del navegador descarta el tipo de color de tu PNG y recodifica cada píxel como RGBA de 32 bits. Pasamos las 83 tarjetas PNG de Open Graph de este sitio por canvas.toBlob('image/png') en Chrome 151.0.0.0. Las 83 volvieron más grandes. El crecimiento mediano fue de +76.6%, con un mínimo de +35.6% y un máximo de +237.2%.

La segunda causa: tu JPEG ya está comprimido. Pásalo por cinco rondas con calidad 0.8 y el tamaño del archivo deja de moverse después de la segunda pasada, mientras cada pasada sigue degradando la imagen.

La tercera: tu PNG ya fue cuantizado. No queda redundancia de color que una segunda pasada pueda eliminar.

Ninguna de estas se arregla bajando el control deslizante de calidad. La solución es otro formato u otro codificador. Esos mismos 83 PNG convertidos a WebP con calidad 0.8 se redujeron todos, con una mediana de −94.2%.

Cómo se obtuvieron estos números. Chrome 151.0.0.0 controlado con Playwright, macOS 26.5.2, Node v25.8.2, upng-js 2.1.0, ImageMagick. El conjunto de 83 archivos es la totalidad de los PNG del directorio public/og de este sitio, no una muestra de ellos. Cuatro archivos controlados adicionales, de 1200×630 y 800×600, cubren por separado los casos de foto, gráfico, paleta y JPEG.

1. La compresión de imágenes no funciona: un triaje de treinta segundos

Busca tu fila y luego lee la sección que indica.

Qué cargaste	Qué obtuviste	Causa raíz	Lee
Captura de pantalla o gráfico PNG	Más grande que el original	canvas lo recodificó como RGBA de 32 bits	Sección 2
Foto JPEG	Más grande que el original	Se guardó como PNG	Sección 2
Foto JPEG	Casi sin cambios	Ya llegó a su meseta de tamaño	Sección 3
PNG que ya pasó por un compresor	Sin cambios, o un poco más grande	No queda margen	Sección 4
Cualquier imagen	Más pequeña, pero borrosa o con el color corrido	Pérdida generacional, o un perfil ICC eliminado	Secciones 3 y 6

Las filas no son mutuamente excluyentes. Una foto JPEG que pasa por un exportador de PNG basado en canvas cae en las dos primeras a la vez, y así es como un archivo de 47,828 bytes termina pesando 809,415 bytes.

Si quieres saltarte el diagnóstico y simplemente obtener un archivo más pequeño, nuestro compresor de imágenes usa un codificador PNG con cuantización en lugar de un viaje de ida y vuelta por canvas, y descarta su propia salida cada vez que el resultado no es más pequeño que lo que subiste.

2. Causa uno: el canvas del navegador siempre escribe RGBA de 32 bits

Qué le hace realmente canvas.toBlob() a tu PNG

En un viaje de ida y vuelta por canvas no hay ningún paso de compresión. Hay una decodificación y una recodificación, y todo lo que no sea un valor de píxel se pierde en el medio.

Dibuja una imagen en un canvas y el navegador la decodifica en un búfer RGBA plano: cuatro bytes por píxel, sin paleta ni metadatos y sin ningún truco de profundidad de bits. Luego HTMLCanvasElement.toBlob() codifica ese búfer desde cero. La especificación PNG define seis tipos de color, y un codificador PNG es libre de elegir el más barato que represente la imagen. El codificador de canvas de Chrome no elige. Siempre emite color type 6.

Tipo de color de entrada	Lo que devuelve canvas.toBlob('image/png')
RGB (color type 2)	RGBA (color type 6)
Paleta (color type 3)	RGBA (color type 6)
JPEG (no tiene color type de PNG)	RGBA (color type 6)

Puedes leerlo directamente de los bytes. El byte 25 de un archivo PNG es la profundidad de bits y el byte 26 es el tipo de color, ambos dentro del chunk IHDR:

xxd -s 24 -l 2 -p suspect.png
# 0806  ->  profundidad de bits 8, color type 6 (RGBA)

Los tres tipos de entrada de arriba produjeron depth=8 type=6. Una imagen con paleta de 64 colores guarda un byte por píxel más una tabla pequeña; después del viaje de ida y vuelta guarda cuatro bytes por píxel y la tabla desapareció. Deflate recupera parte de eso, nunca todo.

Reprodúcelo en tu propio navegador con este fragmento para la consola. Elige un archivo y el fragmento lo pasa por el ciclo completo, e imprime ambos tamaños junto con el tipo de color:

const input = document.createElement('input');
input.type = 'file';
input.accept = 'image/png,image/jpeg';
input.onchange = async () => {
  const file = input.files[0];
  const bitmap = await createImageBitmap(file);
  const canvas = document.createElement('canvas');
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  canvas.getContext('2d').drawImage(bitmap, 0, 0);
  const blob = await new Promise((r) => canvas.toBlob(r, 'image/png'));
  const head = new Uint8Array(await blob.slice(0, 26).arrayBuffer());
  console.log(file.name, file.size, '->', blob.size);
  console.log('bit depth', head[24], 'color type', head[25]);
};
input.click();

El navegador ignora el argumento de calidad de toBlob cuando el tipo es image/png. PNG es sin pérdida, así que un número de calidad no tiene nada que sacrificar, y un control deslizante que aparenta regular la compresión PNG en una herramienta basada en canvas no está regulando nada.

83 archivos medidos: todas las imágenes comprimidas volvieron más grandes que el original

Esta es la corrida completa, sin escoger lo que conviene:

Medición	Valor
Archivos probados	83 (todos los PNG de public/og, con tipos de color RGB y de paleta)
Archivos que crecieron	83 / 83 (100%)
Aumento menor	+35.6%
Aumento mediano	+76.6%
Aumento mayor	+237.2%

Un archivo, para que veas la forma del asunto: aes-decrypt.png pasó de 505,516 B a 898,014 B, un aumento de +77.6%. El mismo archivo codificado como WebP con calidad 0.8 pesa 27,188 B, −94.6%.

Conviene leer con atención los límites de la muestra. Estos 83 archivos son tarjetas de Open Graph: 1200×630, fondos planos, texto grande y un puñado de colores de marca. Son exactamente el tipo de gráfico que un buen codificador PNG maneja bien, y por eso mismo un viaje de ida y vuelta por canvas les hace tanto daño. Es un resultado contundente para los PNG de tipo gráfico; no es una afirmación de que todos los PNG del mundo crezcan al pasar por canvas. Un PNG fotográfico que ya venía guardado como RGBA completo tiene mucho menos que perder.

Lo que sí establece: si tu imagen comprimida es más grande que el original y la herramienta corre en una pestaña del navegador, lo primero que hay que mirar es el codificador, no tu configuración.

Por qué un JPEG guardado como PNG crece 16.9×

Esta es la fila más dramática de todo el conjunto de datos. Cuatro archivos controlados, los cuatro pasados por la misma ruta de canvas:

Archivo	Características	Original	canvas PNG	Cambio	JPEG q92	JPEG q80	WebP q80
og-a.png	Gráfico, 2,351 colores, RGB	306,302	607,481	+98.3%	56,459	37,695	13,852
quantized.png	Paleta de 64 colores	59,843	184,856	+208.9%	78,388	44,442	16,046
photo.png	Foto, 479,373 colores	498,639	867,763	+74.0%	77,321	45,050	24,068
photo.jpg	JPEG q82	47,828	809,415	+1,592% (16.9×)	58,762 (+22.9%)	47,152	23,862

Esa última fila son 47,828 bytes de entrada y 809,415 bytes de salida.

El mecanismo detrás de esto explica toda una familia de reportes del tipo «la compresión lo hizo más grande». JPEG es un códec con pérdida en el dominio de la frecuencia: transforma bloques de 8×8 en coeficientes DCT, los cuantiza con agresividad y guarda a los sobrevivientes. PNG es un códec sin pérdida en el dominio espacial: predice cada píxel a partir de sus vecinos y aplica deflate a los residuos. Decodifica un JPEG y obtienes píxeles que cargan con todos los artefactos que introdujo el cuantizador: halos junto a los bordes, bloques en los degradados suaves y ruido sutil donde el original no tenía ninguno.

Guarda esos píxeles como PNG y le estás pidiendo a un códec sin pérdida que almacene los artefactos a la perfección. Y lo hace. El mismo ruido que JPEG creó para achicar el archivo es ahora lo que agranda el PNG, porque el ruido es justamente lo que un codificador sin pérdida predictivo no puede comprimir.

Dondequiera que un «guardar como PNG» por omisión se interponga delante de una foto, esto está ocurriendo: herramientas de captura de pantalla, exportaciones de diseño, clientes de chat y algunos widgets de subida.

Los mismos píxeles, 3.46× de diferencia, ambos sin pérdida

El codificador de canvas es débil de forma medible. Toma el búfer de píxeles de og-a.png y codifícalo de dos maneras, ambas totalmente sin pérdida:

Codificador	Salida	Tipo de color
Chrome canvas toBlob('image/png')	607,481 B	RGBA (elevación forzada)
upng-js encode(..., cnum=0)	175,491 B	RGB (conserva el color type original)

3.46×, con píxeles idénticos. Verificamos que fuera realmente sin pérdida en lugar de suponerlo: decodificar la salida de upng-js con cnum=0 devuelve un búfer idéntico byte por byte al búfer RGBA de entrada. No sacrificamos nada a cambio de ese 3.46×.

¿Por qué dos compresores en línea, ambos gratuitos y anunciando lo mismo, dan resultados que ni de cerca son comparables? Porque «comprimir en el navegador» describe dos implementaciones completamente distintas. Una le entrega los píxeles a canvas.toBlob y despacha lo que sea que vuelva; la otra lleva adentro un codificador PNG de verdad y controla el tipo de color. Misma entrada, mismo navegador y 3.46× de diferencia.

3. Causa dos: a tu JPEG no le queda nada por dar

Cinco rondas de recompresión, y el tamaño deja de moverse

Toma photo.jpg, que ya venía guardado con calidad 82, y recomprímelo con calidad 0.8 cinco veces seguidas, alimentando cada generación con la anterior:

Generación	Bytes	vs. la anterior
0 (original, q82)	47,828	—
1	47,152	−1.4%
2	47,164	+0.0%
3	47,156	−0.0%
4	47,156	0.0%
5	47,156	0.0%

La primera pasada te compra un 1.4%. A partir de la generación 2 el tamaño del archivo queda encerrado en una banda de ±12 bytes, y las generaciones 4 y 5 tienen un tamaño idéntico al de la generación 3.

Así se ve «la compresión no funciona» cuando la entrada es un JPEG: tanto la herramienta como el codificador hicieron su trabajo, pero no quedaba nada por quitar, porque las tablas de cuantización de calidad 80 ya estaban poniendo en cero aproximadamente los mismos coeficientes que la calidad 82 había conservado. Una vez que un coeficiente desaparece, no se lo puede volver a quitar.

Puedes verlo suceder localmente:

cp photo.jpg gen0.jpg
for i in 1 2 3 4 5; do
  magick "gen$((i-1)).jpg" -quality 80 "gen$i.jpg"
done
stat -f%z gen0.jpg gen1.jpg gen2.jpg gen3.jpg gen4.jpg gen5.jpg

En Linux usa stat -c%s en su lugar. Los conteos exactos de bytes dependen del codificador contra el que se enlace tu compilación de ImageMagick, así que no esperes que la tabla de arriba se reproduzca dígito por dígito. La forma sí se repite: una caída significativa y después una línea plana.

Subir el número de calidad no es comprimir

Mira otra vez la fila de photo.jpg en la sección 2. Recomprimir ese original de calidad 82 con calidad 92 produjo 58,762 bytes: +22.9%.

Esto sorprende a quienes suponen que el parámetro de calidad es una perilla que va de «pequeño» a «grande» y que pueden poner donde se les antoje. No es un objetivo absoluto de calidad. Selecciona una tabla de cuantización, y pasar una imagen ya decodificada por una tabla más fina que la que la produjo guarda los artefactos existentes con más precisión mientras suma encima una ronda nueva de pérdida. Archivo más grande e imagen peor, las dos cosas a la vez.

La regla que se desprende de esto: nunca recomprimas un JPEG con un ajuste de calidad superior al que se usó para guardarlo. Si no sabes cuál fue, no lo recomprimas en absoluto. Vuelve al archivo de origen.

Pérdida generacional: la pérdida de calidad por recomprimir JPEG que no puedes ver

La tabla de la meseta esconde una trampa. El tamaño dejó de cambiar después de la generación 2, pero la imagen siguió cambiando. Cada pasada decodifica a píxeles, vuelve a transformar y vuelve a cuantizar. Los coeficientes que en una generación sobrevivieron justo en el límite quedan del otro lado en la siguiente.

El daño no aparece donde lo buscas. En tamaño miniatura, la generación 5 y la generación 1 son indistinguibles. Acerca al 100% y revisa los lugares donde JPEG siempre falla primero: bordes duros contra fondos planos, texto y degradados suaves donde el bloqueo aparece como mosaicos visibles de 8×8. En un pipeline de compilación que recomprime en cada despliegue, esto se acumula en silencio durante meses.

Aquí medimos tamaños de archivo, no calidad perceptual, así que no vamos a citarte una cifra de PSNR o SSIM para las cinco generaciones. No la medimos. Los datos de tamaño alcanzan por sí solos: desde la generación 2 el costo está por completo del lado de la calidad y el beneficio es cero.

Los corrimientos de color son una falla aparte con el mismo disparador. Canvas no transporta metadatos, así que un viaje de ida y vuelta por toBlob descarta el bloque EXIF y, con él, el perfil ICC. Una imagen etiquetada como Display P3 o Adobe RGB entra y sale sin etiqueta, y los visores la interpretarán como sRGB. Los valores de los píxeles no se movieron. Las instrucciones para interpretarlos, sí.

4. Causa tres: el tamaño del PNG no se reduce porque ya estaba cuantizado

Si tu PNG ya pasó una vez por un compresor, la segunda pasada no tiene con qué trabajar. Esta es la fila de quantized.png, un archivo de 59,843 bytes ya reducido a una paleta de 64 colores, llevado por tres caminos distintos:

Camino	Resultado	vs. el original
Recodificación sin pérdida (upng cnum=0)	61,377	+2.6%
Cuantizar a 256 colores	61,366	+2.5%
Cuantizar a 64 colores	61,366	+2.5%

Todos los caminos terminaron más grandes que el original. No por mucho, pero más grandes, y eso incluye cuantizar a 64 colores un archivo que ya tenía 64 colores.

La compresión PNG funciona quitando redundancia: colores repetidos, vecinos predecibles y paletas chicas. Una pasada anterior ya se llevó todo eso, y lo que queda es casi incompresible. El aumento mínimo es la sobrecarga propia del codificador: otro orden de paleta, otras elecciones de filtro por línea de barrido, un deflate marginalmente menos afortunado.

La consecuencia práctica es que un «0% ahorrado» sobre un PNG ya optimizado es el resultado correcto, no una falla. Una herramienta que informa un aumento pequeño y después conserva tu archivo original se está comportando bien. Una que igual te entrega el archivo más grande, no.

5. La palanca del PNG es la cuantización, no la recodificación

Recodificación sin pérdida frente a 256 colores y a 64 colores

Tres archivos por tres estrategias, medidos:

Archivo	Original	Sin pérdida (cnum=0)	256 colores	64 colores
og-a.png	306,302	175,491 (−42.7%)	110,772 (−63.8%)	76,230 (−75.1%)
photo.png	498,639	587,863 (+17.9%)	109,284 (−78.1%)	61,397 (−87.7%)
quantized.png	59,843	61,377 (+2.6%)	61,366 (+2.5%)	61,366 (+2.5%)

La recodificación sin pérdida es la herramienta más débil disponible. Ganó 42.7% en el gráfico, devolvió 17.9% en la foto y perdió 2.6% en el archivo ya cuantizado. El contenido fotográfico derrota incluso a un codificador PNG sin pérdida competente, porque no hay paleta que encontrar y los píxeles vecinos no se predicen bien entre sí.

La reducción grande está en la cuantización, y la distancia no es pareja: 63.8% frente a 42.7% en el mismo gráfico con 256 colores, y 75.1% con 64. En la línea de comandos:

magick logo.png -colors 64 PNG8:logo-64.png
magick logo.png -colors 256 PNG8:logo-256.png

El prefijo PNG8: fuerza un PNG con paleta. Sin él, ImageMagick puede reducir los colores y aun así escribir un archivo truecolor, lo que tira a la basura casi todo el beneficio.

Cuándo una paleta es segura y cuándo aparecen bandas

La cuantización es con pérdida. Mapea cada píxel a la entrada más cercana de una paleta limitada, así que la pregunta es si tu contenido tiene suficientes colores distintos como para que eso se note.

Seguro: iconos, logotipos, capturas de interfaz, ilustraciones planas, diagramas, cualquier cosa con regiones grandes de color uniforme y bordes duros. Suelen contener unos pocos cientos de colores distintos como máximo, así que una paleta de 256 entradas sale casi gratis e incluso 64 muchas veces aguanta.

Riesgoso: fotografías, degradados suaves, sombras difusas y capas semitransparentes. Reducir un degradado a 64 pasos produce bandas visibles, y el tramado cambia esas bandas por ruido que después te cobra de vuelta parte del tamaño del archivo. La transparencia parcial sobre un degradado es el caso más difícil de todos.

La transparencia merece su propia revisión, porque cuánta sobrevive depende del codificador y no de la cuantización en sí. El PNG8: de ImageMagick escribe transparencia binaria, así que un píxel queda completamente opaco o completamente transparente, y un borde suavizado vuelve duro. Un cuantizador PNG dedicado conserva el canal alfa completo y, con él, el borde suave. Si tu recurso tiene una sombra difusa o bordes difuminados, compara los dos antes de decidirte.

Revisa el resultado al 100%, no en una miniatura. Las bandas son el artefacto que una vista previa reducida esconde sin falta.

6. La solución: cambia de formato en lugar de recomprimir

Una tabla de decisión de formatos

Contenido	Usa	Por qué
Fotografías	WebP, o JPEG para máxima compatibilidad	La codificación en frecuencia con pérdida es lo que las fotos necesitan
Capturas de pantalla, gráficos de interfaz	PNG cuantizado, o WebP	Colores planos, bordes duros, paletas pequeñas
Iconos y logotipos	SVG cuando tengas el vector; si no, PNG cuantizado	Los vectores no tienen problema de resolución
Cualquier cosa que necesite transparencia	WebP o PNG	Los dos llevan un canal alfa completo
Animación	WebP	Un solo formato en lugar de un GIF
Archivado con exactitud de píxel	PNG, sin pérdida	El único caso en que lo sin pérdida es el requisito

Esta es la versión corta, a propósito. La eficiencia de codificación y el soporte de los navegadores entre los formatos modernos tienen su propio artículo: WebP vs AVIF vs JPEG.

Qué hizo WebP con esos mismos 83 archivos

El mismo conjunto de 83 archivos que creció el 100% de las veces al pasar por PNG de canvas, convertido a WebP con calidad 0.8, dio el resultado contrario: 83 de 83 se hicieron más pequeños, con una mediana de −94.2%. El archivo suelto de antes, aes-decrypt.png, pasó de 505,516 B a 27,188 B, −94.6%.

Los archivos controlados coinciden. og-a.png: 306,302 como PNG, 13,852 como WebP q80. photo.png: 498,639 como PNG, 24,068 como WebP q80. photo.jpg: 47,828 como JPEG, 23,862 como WebP q80.

Una advertencia sobre esa última comparación. WebP con calidad 0.8 es con pérdida, así que no compite con PNG en igualdad de condiciones, y recodificar un JPEG existente a WebP te sigue costando una generación. La comparación útil es contra lo que estabas a punto de publicar, no contra un original perfecto hipotético.

Cuándo conviene quedarse con el PNG de todos modos

A veces lo sin pérdida es el requisito, no una preferencia. Quédate con PNG para los recursos que vuelven a un pipeline de diseño y se editan otra vez, para capturas usadas en pruebas de comparación de píxeles, para recortes de interfaz donde un solo color corrido rompe un diff visual, y para todo lo que después se vaya a componer, donde los artefactos de cuantización se acumularían. En esos casos, usa un codificador con cuantización de verdad si el contenido lo permite, y acepta el tamaño del archivo si no.

Otro tipo de «más grande» que no tiene nada que ver con la compresión

Si incrustas imágenes como data URI, el tamaño en tu CSS o HTML no es el tamaño en disco. Base64 codifica cada 3 bytes como 4 caracteres, más el relleno, así que el texto es aritméticamente +33% más grande que los bytes que transporta, antes de cualquier compresión de transferencia. Una imagen perfectamente optimizada igual crece un tercio en cuanto la incrustas. Nuestra guía sobre incrustar con data URI explica cuándo vale la pena hacer ese intercambio.

7. Manos a la obra: navegador, línea de comandos, pipeline de compilación

En el navegador

Al elegir una herramienta basada en navegador, la distinción está en si el PNG pasa o no por canvas. En nuestro compresor de imágenes no pasa. La entrada PNG se cuantiza a una paleta de colores y se vuelve a escribir como un PNG real con su canal alfa intacto, de modo que la transparencia y los bordes suaves sobreviven; el control deslizante de calidad corresponde a un tamaño de paleta y no a un argumento de toBlob que PNG ignoraría de todas formas. La calidad 100 corresponde a una recodificación sin pérdida. JPEG y WebP sí pasan por canvas, donde el parámetro de calidad es real y hace lo que esperas.

Hay un comportamiento que conviene conocer porque parece un error y no lo es: si el resultado comprimido no es más pequeño que el archivo que subiste, la herramienta descarta su propia salida y conserva tus bytes originales. En un PNG ya optimizado verás «0% ahorrado». Eso es la sección 4 funcionando como corresponde.

Todo el procesamiento ocurre en tu propio equipo; los archivos no salen del navegador.

En la línea de comandos

cwebp viene con libwebp y es la forma más rápida de probar si un cambio de formato resuelve tu problema:

# WebP con pérdida, calidad 0-100
cwebp -q 80 photo.png -o photo.webp

# WebP sin pérdida, esfuerzo de compresión 0-9
cwebp -z 9 logo.png -o logo.webp

ImageMagick 7 cubre los casos de conversión y de cuantización:

# De PNG a JPEG con la calidad elegida
magick photo.png -quality 80 photo.jpg

# Cuantizar a un PNG con paleta de 64 colores
magick logo.png -colors 64 PNG8:logo-64.png

# Descartar EXIF y otros metadatos
magick photo.jpg -strip photo-clean.jpg

En macOS, sips ya viene instalado y no necesita dependencias:

# Convertir a JPEG; formatOptions acepta 0-100 o low/normal/high/best
sips -s format jpeg -s formatOptions 80 photo.png --out photo.jpg

# Redimensionar para que el lado más largo mida 1200 px, conservando la relación de aspecto
sips -Z 1200 photo.jpg --out photo-1200.jpg

# Leer de vuelta las dimensiones
sips -g pixelWidth -g pixelHeight photo-1200.jpg

Redimensiona antes de comprimir. Los codificadores trabajan sobre píxeles, y el píxel más barato es el que no existe.

En un pipeline de compilación

Cuando esto se automatiza en lugar de hacerse a mano, la decisión se traslada a dónde ocurre el trabajo y a qué biblioteca lo hace, lo que cambia los compromisos por completo: compresión de imágenes en el navegador frente a Node.js cubre esa comparación. La única regla que sobrevive de este artículo: comprime desde el archivo fuente original en cada compilación, nunca desde la salida de la compilación anterior. Así es como un pipeline se va deslizando por la curva de pérdida generacional mientras los tamaños de archivo se ven perfectamente estables.

8. Cinco creencias que las mediciones no respaldan

«Comprimir dos veces lo hace más pequeño». La generación 1 compró un 1.4%. Las generaciones 2 a 5 se mantuvieron dentro de ±12 bytes mientras la imagen seguía degradándose. La segunda pasada es puro costo.

«PNG es sin pérdida, así que es el mejor formato». Sin pérdida es una propiedad, no una virtud. Nuestra foto de prueba pesa 498,639 bytes como PNG y 24,068 como WebP q80. Conservar una fotografía bit a bit cuando solo se va a ver en una pantalla no compra nada y cuesta casi todo el archivo.

«La calidad 100 es la opción segura». Recomprimir un JPEG de calidad 82 con calidad 92 produjo +22.9% y una imagen peor. Por encima del ajuste de calidad del original, el número deja de significar «más seguro» y pasa a significar «más grande».

«El archivo es grande porque la resolución es alta». La resolución importa, pero a igual resolución el formato importa más. og-a.png mide 1200×630 en los dos casos: 607,481 bytes como PNG de canvas, 13,852 bytes como WebP q80. Idéntica cantidad de píxeles.

«Los compresores en línea son todos iguales». Mismos píxeles, mismo navegador, ambos sin pérdida: 607,481 bytes desde canvas, 175,491 desde upng-js. Una diferencia de 3.46× entre dos herramientas que se describen de forma idéntica.

9. Preguntas frecuentes

¿Por qué mi imagen comprimida es más grande que el original?

Porque la herramienta la recodificó en lugar de comprimirla. La salida del canvas del navegador siempre es un PNG RGBA de 32 bits, que descarta las paletas y guarda cuatro bytes por píxel. En nuestra prueba con 83 PNG reales, los 83 crecieron, con un aumento mediano de +76.6%. Convierte a WebP o JPEG en su lugar.

¿Por qué mi PNG no se hace más pequeño cuando lo comprimo?

PNG es sin pérdida, así que un control deslizante de calidad no tiene nada que sacrificar. La reducción real viene de recortar la cantidad de colores, y si el archivo ya estaba cuantizado no queda nada por recortar. Nuestro PNG de prueba de 64 colores volvió con +2.5% después de cuantizarlo a 64 colores por segunda vez.

¿Comprimir un JPEG dos veces le quita calidad?

Sí, y casi no obtienes nada a cambio. Cinco rondas con calidad 0.8: de 47,828 bytes a 47,152 en la primera pasada, y después encerrado dentro de 12 bytes en las cuatro siguientes. El tamaño dejó de moverse mientras cada pasada seguía recuantizando la imagen. Guarda tus originales.

¿Debo usar PNG o JPEG para achicar un archivo?

Para fotografías, JPEG o WebP, sin excepción. Nuestra foto de prueba midió 498,639 bytes como PNG, 45,050 como JPEG q80 y 24,068 como WebP q80. Reserva PNG para gráficos planos, texto nítido y transparencia, donde una paleta chica hace el trabajo de compresión.

¿Por qué mi imagen quedó borrosa después de comprimirla?

Dos causas distintas. Los codificadores con pérdida en ajustes de calidad bajos producen bloques visibles alrededor de los bordes y del texto. Las pasadas repetidas suman pérdida generacional aunque el tamaño del archivo deje de cambiar. Si los colores se corrieron en lugar de suavizarse, el viaje de ida y vuelta por canvas descartó tu perfil ICC, ya que canvas no transporta ningún metadato.

¿Puedo comprimir una imagen sin perder calidad?

Sí, pero espera mucho menos. La recodificación sin pérdida solo reescribe píxeles idénticos de forma más eficiente: de 306,302 a 175,491 bytes en nuestro gráfico, verificado idéntico byte por byte tras decodificarlo. El mismo enfoque en una foto fue en la dirección contraria, +17.9%. Para un ahorro real sin pérdida visible, usa WebP con calidad 80.

¿Por qué mi PNG es tan grande si es solo una captura de pantalla?

Las capturas de pantalla se guardan como PNG RGBA completo, cuatro bytes por píxel antes de comprimir, y una pantalla Retina duplica la cantidad de píxeles en cada dimensión. El contenido plano responde bien a la reducción de paleta: nuestro gráfico de tarjeta de Open Graph bajó 63.8% con 256 colores y 75.1% con 64.

¿Redimensionar reduce el tamaño del archivo más que comprimir?

Casi siempre, y las dos cosas se potencian. Reducir a la mitad ambas dimensiones elimina tres cuartas partes de los píxeles antes de que arranque el codificador, y el tamaño del archivo sigue a grandes rasgos la cantidad de píxeles. Primero redimensiona a las dimensiones que realmente muestras, después comprime una sola vez. Un archivo de cámara a resolución completa metido en un hueco de miniatura desperdicia las dos pasadas.