Por qué una imagen comprimida pesa más y cómo evitarlo

Pasaste una imagen por un compresor o un conversor y lo que descargaste pesa más que el archivo original. Casi nunca es un error: el codificador describe los píxeles que recibe en el formato que le pediste, y a veces esa descripción ocupa más que la que ya tenías.

Respuesta corta: el archivo crece cuando los ajustes nuevos conservan más de lo que conservaba el archivo anterior (un JPEG muy comprimido guardado otra vez con más calidad), cuando una foto con pérdida pasa a un formato sin pérdida (de JPG a PNG), cuando el codificador abandona un recurso que usaba el original (un PNG con paleta guardado de nuevo en 32 bits), cuando la estructura fija del formato pesa más que una imagen diminuta o cuando aumenta el número de píxeles. En nuestras pruebas, un JPEG de 135 kB se convirtió en un PNG de 2,21 MB, y un icono de 504 bytes pasó a 1.104 bytes en WebP. La solución suele ser quedarte con el original, elegir otro formato o bajar la calidad; en cada sección indicamos cuál.

Los nueve casos de un vistazo

Todas las cifras salen de una única ejecución en nuestro equipo. Los tamaños están en bytes exactos; en el texto, 1 kB son 1.000 bytes.

Cómo hicimos las pruebas

Lo ejecutamos todo el 16 de octubre de 2026 (UTC) en un Mac con Apple M4 y macOS 26.6.2.

• Codificadores del navegador: Google Chrome 155.0.8059.85 en modo headless. Cargamos browser-image-compression 2.0.2, la biblioteca que usa nuestro compresor de imágenes, en una página local vacía y la llamamos con los ajustes por defecto del compresor: calidad 0,8, tamaño objetivo de 1 MB, lado largo máximo de 1.920 px, formato original conservado, EXIF eliminado y hasta 30 pasadas de reintento. En los casos de conversión usamos las mismas llamadas de canvas que nuestras páginas de conversión: dibujar la imagen, rellenar el fondo de blanco para JPG y llamar a canvas.toBlob con la calidad por defecto del conversor, 90 %. No hicimos clic en el propio sitio; el código es el mismo, pero la página que lo rodeaba era de prueba.
• Otros codificadores: sharp 0.35.5 en Node v26.12.0 (libvips 8.18.7, mozjpeg, libwebp 1.6.0, libaom 3.15.1, libimagequant 2.4.1, libpng 1.6.58) y upng-js 2.1.0, el codificador PNG/APNG que usa nuestro conversor de GIF a APNG.
• Imágenes: una foto de paisaje CC0 de Bonnie Moreland (Wikimedia Commons), tomada de la salida de nuestro compresor en una prueba anterior (1920 x 1280, 250.382 bytes), y una versión recodificada con mozjpeg a calidad 70 (135.151 bytes); la imagen de prueba kodim04 de Kodak (PNG de 512 x 768, liberada por Kodak para uso sin restricciones); una captura de nuestra propia página /compress (PNG de 1440 x 900); el logotipo CC0 "NEW LOGO R" de Enzy Cell (Wikimedia Commons) y una versión con paleta; un icono de 32 x 32 y un GIF de 12 fotogramas que dibujamos para esta prueba; y una miniatura de 320 px de ancho recortada de kodim04.

Cada cifra corresponde a una sola ejecución. El codificador PNG del navegador no produce los mismos bytes en cada ejecución, así que si repites la prueba verás pequeñas diferencias. Nosotros hacemos ImgCompress.app, y en Sobre nosotros se explica quién lleva el sitio. El texto se redactó con ayuda de un asistente de IA, y contrastamos cada cifra con los archivos de salida.

¿Por qué un JPEG pesa más al volver a comprimirlo?

Porque "calidad 80" no equivale a una cantidad fija de compresión. Es un ajuste de un codificador concreto, y cada codificador, o cada valor de calidad, conserva una cantidad distinta de detalle.

Nuestro JPEG de prueba de 135 kB se había generado con mozjpeg a calidad 70, un ajuste pensado para archivos pequeños. Cuando el codificador integrado de Chrome lo guardó de nuevo con calidad 80, salieron 168 kB, un 24 % más. El navegador decodificó el JPEG a píxeles sin más, incluido el ruido en bloques que mozjpeg había dejado, y codificó esos píxeles con una cuantización más fina que la del original. Lo que se perdió la primera vez no vuelve; el archivo nuevo gasta más bytes en la misma imagen y en los artefactos antiguos.

La versión menos comprimida de la misma foto, de 250.382 bytes, se comportó de otra forma. Chrome con calidad 80 dio 250.670 bytes, solo 288 bytes más. Guardarla de nuevo con el mismo codificador y el mismo ajuste que la habían generado dejó el tamaño casi idéntico al original.

Qué hace nuestro compresor en este caso

Nuestro compresor revisa el primer resultado. En browser-image-compression, si la salida pesa más que el archivo de origen (o supera el tamaño objetivo), vuelve a codificar con 0,95 veces la calidad anterior (0,85 para PNG) y repite hasta que el archivo queda por debajo de ambos límites o se acaban las pasadas. Las dimensiones solo se reducen en ese bucle cuando el archivo supera el tamaño objetivo, así que una foto pequeña conserva su tamaño en píxeles.

Con el archivo de 250 kB, una pasada más a calidad 0,76 lo dejó en 240.546 bytes, un 3,9 % menos. Con el de 135 kB de mozjpeg hicieron falta siete pasadas, hasta calidad 0,56, para llegar a 134.643 bytes. Son 508 bytes ahorrados a cambio de una calidad mucho más baja en un archivo que ya estaba comprimido. Si la tarjeta de resultado muestra un ahorro de unos pocos puntos porcentuales o menos, quédate con el original.

Si el resultado sigue sin ser más pequeño y el formato no cambió, el compresor te devuelve el archivo original, de modo que nunca te entrega un archivo más grande en el mismo formato.

La explicación detallada de los valores de calidad está en nuestra guía de compresión JPEG.

¿Por qué mi PNG pesa tanto más después de convertirlo desde JPG?

PNG es un formato sin pérdida. Guarda cada píxel tal cual, y una foto JPEG decodificada tiene muchísimos píxeles que difieren un poco de sus vecinos: grano, ruido del sensor y el leve patrón de bloques de 8 x 8 que añade la compresión JPEG. Un formato sin pérdida tiene que guardarlo todo.

En nuestra prueba, cuanto más comprimido estaba el JPEG, mayor fue el salto, porque el archivo de partida era más pequeño y el PNG tenía que guardar el mismo número de píxeles. Convertir a PNG tampoco deshace el daño del JPEG: el desenfoque y los bloques siguen ahí, solo que ahora guardados sin pérdida.

Convierte de JPG a PNG cuando necesites PNG en concreto: un editor que solo acepta PNG, una copia maestra que vas a editar muchas veces o un formulario que rechaza JPG. Si lo que buscas es un archivo más pequeño, quédate en JPG o pasa a WebP o AVIF.

¿Por qué creció mi PNG al guardarlo de nuevo?

Aquí hay dos cosas del navegador que juegan en tu contra.

La primera: el codificador PNG del canvas de Chrome empaquetó los datos con mucha menos eficiencia que el archivo que recibió. Guardar la foto kodim04 con canvas.toBlob convirtió 637.432 bytes en 846.413 bytes, un 33 % más, con los mismos píxeles. Ni siquiera un guardado sin pérdida hecho con cuidado gana siempre: sharp con libpng al nivel de compresión 9 produjo 638.304 bytes, 872 bytes más que el archivo de partida.

La segunda: un canvas trata todas las imágenes como RGBA de 32 bits, y eso es lo que escribió Chrome. Un PNG con paleta guarda cada píxel como un índice a una tabla de colores pequeña, que es como herramientas como TinyPNG y pngquant consiguen archivos tan ligeros. Nuestra versión con paleta del logotipo pesaba 45.525 bytes. Al dibujarla en un canvas y guardarla otra vez pasó a 170.429 bytes, 3,7 veces más, porque la tabla de colores desapareció y cada píxel se guardó completo.

Nuestro compresor no usa canvas.toBlob sin más para PNG. browser-image-compression pasa los píxeles a UPNG con un límite de colores de 4096 multiplicado por la calidad, es decir, 3.276 colores con el valor por defecto de 0,8. Resultados de la misma ejecución:

Este paso reduce colores, así que no es sin pérdida: la foto pasó de 31.716 colores distintos a 3.277, y la captura de 2.002 a 1.314. En PNG con paleta ya optimizados queda poco por ganar, así que volver a comprimirlos con cualquier herramienta, incluida la nuestra, casi nunca compensa.

¿Conviene guardar una captura de pantalla como JPG?

Normalmente no. JPEG está pensado para el detalle suave de las fotografías, y las capturas son colores planos con bordes nítidos alrededor del texto. Chrome guardó nuestro JPG con submuestreo de croma 4:2:0, que almacena el color a la mitad de la resolución del brillo en ambas direcciones; donde antes se nota es en el texto de color y en las líneas finas de color. En nuestro recorte ampliado al 200 % con calidad 90, costaba ver la diferencia con el PNG, pero el archivo seguía pesando más.

Si un sitio exige JPG, PNG a JPG al 80 % quedó por debajo del tamaño del PNG en nuestra prueba; al 90 %, no. Donde se acepte WebP, PNG a WebP es mejor cambio para capturas. El PNG con paleta fue el archivo más pequeño de todos, y nosotros no ofrecemos un modo de paleta de 256 colores, así que usa una herramienta como pngquant o Squoosh cuando necesites rascar esos últimos 50 kB. Las ventajas e inconvenientes de esos dos formatos están en WebP vs PNG.

¿Por qué WebP o AVIF salen más grandes que el original?

Hay dos motivos distintos, y aparecieron en dos pruebas diferentes.

Convertir con calidad alta un JPEG ya comprimido

WebP y AVIF suelen pesar menos que JPEG con la misma calidad visual. Esa comparación da por hecho que partes de un original limpio. Si partes de un JPEG, el codificador nuevo tiene que reproducir los artefactos del JPEG como si fueran detalle.

El JPEG de 250 kB pasó de 250.382 a 269.556 bytes como WebP con calidad 90, un 7,7 % más. Pesa más el valor de calidad que el formato. Cuando uses JPG a WebP, baja el control desde el 90 % por defecto y compara tamaños, o prueba JPG a AVIF. En nuestro análisis a fondo de AVIF explicamos qué le hace AVIF a la textura fina.

Imágenes diminutas y costes fijos

Cada formato tiene costes fijos, como las cabeceras y, en WebP con pérdida y transparencia, un canal alfa guardado aparte. Pesan mucho cuando la imagen entera ocupa 504 bytes.

WebP sin pérdida sí ganó al PNG por 140 bytes, pero casi todas las demás opciones agrandaron el icono, incluidos los dos ajustes de AVIF. Para iconos y gráficos pequeños de interfaz, quédate con el PNG, o usa SVG si tienes el original vectorial. En nuestras pruebas, WebP y AVIF ahorraron bytes en las fotos, no en el icono.

¿Ampliar la imagen o conservar los metadatos añade peso?

Ampliar añade bytes sin añadir detalle. Nuestra miniatura de 320 x 480 pesaba 28.034 bytes. Guardada de nuevo a su tamaño con calidad 80 quedó en 28.513 bytes; ampliada antes a 640 x 960, en 62.114 bytes: 2,2 veces más por una imagen más blanda. Nuestro compresor nunca amplía, porque su ajuste de 1.920 px es un máximo. Un redimensionador sí amplía si escribes cifras mayores, así que revisa el tamaño de destino en el redimensionador de imágenes antes de exportar. En redimensionar sin perder calidad explicamos por qué ampliar no recupera detalle.

Los metadatos influyeron poco en nuestra prueba. La miniatura llevaba un perfil de color Display P3 de 480 bytes y etiquetas EXIF de 258 bytes, alrededor del 2,6 % de sus 28.290 bytes. Nuestro compresor elimina los EXIF por defecto y solo los conserva si activas "Conservar EXIF". Los archivos de cámara pueden llevar bloques más grandes, como imágenes de vista previa incrustadas, así que en exportaciones pequeñas desde una cámara o un teléfono quitar los EXIF puede pesar más. También elimina la ubicación GPS.

¿Qué pasa al convertir un GIF?

GIF es antiguo, pero para una animación corta con pocos colores planos es compacto, porque guarda índices de paleta y puede guardar solo la parte de cada fotograma que cambió. Dibujamos una animación de 12 fotogramas y 240 x 240 de un punto que cruza un fondo liso:

Ninguna opción cambió mucho el tamaño. Este resultado solo vale para una animación pequeña de colores planos; no probamos GIF largos con fotogramas fotográficos, donde el límite de 256 colores y el tramado le cuestan más a GIF. Para animaciones cortas y planas, quedarte con el GIF es una opción razonable, y si lo necesitas más pequeño, empieza por el compresor de GIF.

Qué hacen nuestras herramientas cuando el resultado pesa más

Todo el procesamiento descrito se hace en tu navegador; en nuestro sitio la imagen no se sube a ningún servidor. Esto es lo que hace cada herramienta cuando la salida crece:

• Compresor, con el formato original: reintenta con menos calidad mientras el archivo pese más que el de origen y, si aun así no queda más pequeño, te devuelve el original.
• Compresor, con cambio de formato: recibes el archivo convertido aunque pese más. La tarjeta de resultado muestra los dos tamaños, y el porcentaje solo aparece cuando el archivo se redujo, así que compara las dos cifras.
• Conversores: codifican una sola vez con el valor del control (90 % por defecto en las salidas con pérdida), sin comprobar el tamaño. Convertir tiene que ver con el formato, así que el tamaño puede subir o bajar.
• Tamaño objetivo: mientras el archivo supere tu objetivo, cada pasada baja la calidad y, salvo que esté activado "Forzar resolución original", reduce el ancho y el alto un 5 %. Se detiene tras 30 pasadas; si no alcanzó el objetivo, la tarjeta lo indica.

Lista de comprobación antes de volver a comprimir o convertir

1. ¿El archivo ya está optimizado? Si viene de una CDN, un CMS o una herramienta como TinyPNG, una segunda pasada suele ahorrar poco; la nuestra ahorró un 3,9 % y un 0,4 %. Con una ganancia así, quédate con el original.
2. ¿Vas a pasar una foto a PNG? Hazlo solo si te exigen PNG. Nuestros dos JPEG crecieron 10,7 y 16,4 veces.
3. ¿Es una captura de pantalla o un gráfico plano? Mantén PNG o usa WebP. En nuestra prueba, JPG al 90 % pesó más que el PNG.
4. ¿Pesa menos de unos pocos kB? Deja los iconos en PNG o SVG. Las cabeceras de WebP y AVIF pueden pesar más que los píxeles.
5. ¿Aumentaron las dimensiones en píxeles? Revisa el tamaño de salida antes de guardar. Ampliar duplicó los bytes de nuestra miniatura.
6. ¿El conversor está al 90 %? De JPG a WebP, prueba entre el 75 y el 80 % y compara.
7. ¿Necesitas los metadatos? Quita los EXIF en imágenes públicas pequeñas; consérvalos en las fotos que archivas.

Si solo quieres un archivo más pequeño en el mismo formato, empieza por el compresor y compara los tamaños de antes y después en la tarjeta de resultado antes de descargar.