Por qué comprimir dos veces no reduce dos veces a la mitad

La compresión quita redundancia, no volumen

La imagen mental que lleva casi todo el mundo es mecánica: el archivo es una esponja, la herramienta la aprieta, y apretar más fuerte o dos veces saca más. Esa imagen predice que una segunda pasada debería ayudar, y se equivoca sobre lo que hace la máquina. Un compresor busca patrones —una secuencia de bytes ya aparecida, un color repetido en una zona, una entrada de diccionario que sustituya a una palabra larga— y reemplaza cada aparición por una referencia más corta. Lo que sale no son los mismos datos apretados. Es una descripción distinta, más breve, de los mismos datos.

Una vez hecha esa reescritura, las repeticiones son referencias y las referencias no se repiten. Un segundo compresor llega a un archivo que parece, estadísticamente, ruido —que es exactamente el aspecto de los datos bien comprimidos— y no encuentra nada que acortar. Aún debe escribir su propia cabecera y su envoltura, así que la salida es a veces un pelo mayor que la entrada. Una herramienta que informa de un ahorro nulo o negativo en la segunda pasada no está fallando: dice la verdad sobre un archivo ya tratado.

Hay un suelo, y tiene nombre

En 1948 Claude Shannon demostró que todo cuerpo de datos tiene un tamaño mínimo por debajo del cual ningún método sin pérdida puede llevarlo. Ese mínimo es su entropía: una medida de cuánto de los datos es genuinamente impredecible. Una página de texto en español es muy predecible —tras «qu» una «e» es muy probable— así que comprime bien. Un flujo de números aleatorios no es predecible en absoluto, así que no comprime, y ningún algoritmo futuro lo cambiará. Las herramientas de compresión no compiten por apretar más fuerte; compiten por modelar mejor los datos y acercarse a un límite ya fijado.

Por eso el experimento familiar de comprimir un PDF en zip no gana nada que valga. Los flujos internos del PDF ya están comprimidos con deflate y sus imágenes ya son JPEG; el archivo está cerca de su entropía, y el zip no tiene con qué trabajar. Lo mismo vale para un MP4, un MP3 y un PNG. Si un tipo de archivo termina en un formato diseñado para ser pequeño, supón que la compresión ya está hecha y que un archivador genérico añadirá embalaje en vez de quitar volumen.

Con pérdida es otra máquina con otro fallo

La compresión con pérdida no está limitada por la entropía, porque no tiene que reproducir el original. Decide qué no notará una persona —variaciones finas de color, detalle de alta frecuencia, sonidos enmascarados por otros más fuertes— y lo descarta. Por eso un JPEG es la décima parte de la imagen bruta de la que viene, y por eso la segunda pasada se comporta tan distinto: siempre queda más que descartar, así que el archivo siempre encoge, y la pregunta pasa de «¿se puede?» a «¿a qué coste?».

El coste es la pérdida de generación, y se acumula de un modo que sorprende. Cada recodificación empieza decodificando el resultado anterior, que ya contiene los artefactos que introdujo la pasada previa. La nueva pasada trata esos artefactos como detalle real digno de preservarse, gasta bits en ellos y añade los suyos. Cinco guardados con buena calidad producen una salida visiblemente peor —bloques en los bordes, manchas de color, un empastado general— que un solo guardado con calidad mucho más baja que alcanza el mismo tamaño. La regla que se deriva es la única que importa en la práctica: comprime siempre desde el original, nunca desde una copia comprimida.

¿Cuál de los dos hace una herramienta dada?

El comportamiento te lo dice. Una herramienta sin pérdida da un ahorro modesto y repetible en la primera pasada y prácticamente nulo en la segunda, y su salida es idéntica píxel a píxel a la entrada. Una herramienta con pérdida ofrece un control de calidad o preajustes —ligero, medio, fuerte— y sigue produciendo archivos más pequeños según aprietas. Si una herramienta lleva un PDF escaneado de 20 MB a 3 MB, está recodificando las imágenes y es con pérdida, diga lo que diga el botón. El compresor de este sitio es del primer tipo: reescribe la estructura de objetos del PDF y deja intacto cada byte de imagen, así que nunca te dará una cifra espectacular en un escaneo, y nunca degradará en silencio un documento que vas a presentar en algún sitio oficial.

El único caso en que una segunda pasada ayuda de verdad

Ejecutar el mismo algoritmo dos veces no sirve. Ejecutar otro distinto sobre el mismo original, sí. Un método más fuerte, con mejor modelo de los datos —un archivador moderno en vez de uno clásico, o un formato de imagen más nuevo en lugar de uno antiguo— puede batir el primer resultado, porque es un mejor intento contra el mismo límite y no un segundo intento contra un problema ya resuelto. Recodificar un JPEG a AVIF o WebP desde el archivo original suele quedar más pequeño a igual calidad; volver a comprimir un zip, no.

Dos consecuencias prácticas. Guarda los originales: en cuanto solo tienes la copia comprimida, toda mejora futura de formatos te queda cerrada, porque ya no puedes comprimir desde algo intacto. Y cuando un archivo sigue tercamente demasiado grande tras una pasada honesta, deja de recurrir al compresor y cambia algo estructural: menos páginas, menor resolución, un fragmento más corto, una división en dos archivos. Son decisiones sobre el contenido, y en el contenido es donde están realmente los bytes que quedan.

Qué hacer en vez de volver a pulsar el botón

Haz la pasada sin pérdida una vez y toma la cifra que da como la verdad sobre ese archivo. Si no basta, identifica dónde están los bytes antes de nada: en un PDF, divide el tamaño entre las páginas; en un vídeo, multiplica la duración por la tasa de bits; en una imagen, mira las dimensiones en píxeles. Luego actúa sobre esa cosa concreta, una vez, desde el original. Dos decisiones tomadas con deliberación valen más que cinco pasadas hechas con esperanza, y te dejan un archivo más pequeño que no ha pasado cinco veces por el molino.

Preguntas frecuentes

Mi archivo creció al comprimirlo. ¿Cómo es posible?

Porque el compresor aún debe escribir su propia contabilidad —una cabecera, un diccionario, una envoltura alrededor de los datos— y si no encuentra redundancia que quitar, esa contabilidad es pura adición. Es el resultado normal con datos ya comprimidos o realmente aleatorios, y es una señal más que un fallo: el archivo ya estaba en su suelo o cerca. Guarda el original y pasa a un cambio estructural.

¿Significa esto que la compresión sin pérdida es débil?

No: significa que es honesta. Con datos de redundancia real es muy eficaz: un volcado de base de datos, un archivo de registro o un PDF con mucho texto pueden perder una gran parte de su tamaño sin que cambie un solo bit de información. Lo que no hará es inventar espacio donde no lo hay, ni degradará tu documento para producir una cifra más bonita. En todo lo que puedas tener que defender después —una presentación, un contrato firmado, un escaneo original— esa es justo la propiedad que quieres.

¿Se ve la pérdida de generación con un solo reguardado?

Rara vez, con un ajuste de calidad razonable y si no cambió nada más. Se hace visible cuando los reguardados se acumulan, cuando el ajuste de calidad es bajo, o cuando la imagen además se redimensiona entre guardados: redimensionar fuerza una recodificación completa e interactúa mal con los artefactos de bloque existentes. La costumbre segura no es contar pasadas sino evitar la situación: guarda el original y produce cada salida que necesites directamente desde él y no desde lo último que exportaste.

¿Por qué la misma herramienta ahorra un 40 % en un PDF y un 2 % en otro?

Porque el ahorro depende por completo de cuánta redundancia llevaba el archivo, y eso varía enormemente según cómo se hizo. Un PDF exportado varias veces desde un editor, o generado por un sistema de plantillas que repite una definición en cada página, está lleno de duplicación eliminable. Un PDF escrito una vez por una biblioteca bien educada, o que es esencialmente una pila de fotografías, casi no tiene. El porcentaje es un hecho sobre la historia del archivo, no una nota a la herramienta.

¿Debo poner encima un archivador más fuerte, como 7-Zip?

Solo con datos que aún no se han comprimido. Un archivador más fuerte tiene mejor modelo y ganará a uno más débil con texto, código fuente, bases de datos y volcados en bruto, a veces por mucho. En un PDF, JPEG, MP3 o MP4 trabaja sobre datos ya cerca de su suelo, y la ganancia será de un uno o dos por ciento a cambio de un contenedor que el destinatario debe descomprimir. Usa el archivador fuerte donde vive la redundancia, no en archivos a los que ya se la quitaron.