Guarda lo mismo ocupando la mitad
vcompresor es nuestro archivador. Sobre el mismo material y en la misma máquina deja los ficheros un 35% más pequeños que 7-Zip y que xz, y un 15% más pequeños que zpaq. No es un ajuste de otro compresor: es un motor propio, escrito de cero, sin una sola dependencia externa.
Deshace los formatos en vez de tragárselos
Un archivador normal ve un PNG, un .docx o un .zip como bytes opacos: ya vienen comprimidos y no puede hacer nada con ellos. vcompresor los despliega, modela lo de dentro, y al extraer los vuelve a montar exactamente igual.
Recompresión reversible
Deshace el DEFLATE que llevan dentro los PNG, los .gz, los ZIP y todo lo que va en ZIP —docx, xlsx, pptx, jar, apk, epub— y también el JPEG. La reconstrucción se verifica al comprimir: si no sale byte-idéntica, ese fichero se guarda tal cual. Nunca se cambia correctitud por tamaño.
El mismo archivo en cualquier máquina
No hay una sola operación de coma flotante en el camino de la probabilidad. Comprimir el mismo dato en un Intel y en un ARM da el mismo SHA-256, y cada uno abre el del otro. Para archivo verificable, almacenamiento por contenido o cumplimiento normativo eso no es un detalle — y los compresores que más comprimen no lo tienen.
Se monta como una carpeta
Un archivo .vc se monta y se navega por dentro sin desempaquetarlo. Y de fondo: deduplicación por contenido, reordenado de ficheros por parecido antes de empaquetar, un carril que saca los sellos de tiempo de los logs, filtro para ejecutables y extracción en paralelo.
Contra el campo entero, en la misma máquina
Once herramientas sobre exactamente el mismo material: 136.475.130 bytes en 9.491 ficheros de código, un corpus congelado y sellado por manifiesto. Todo medido el 17 de agosto de 2026, en la misma tanda y en el mismo servidor. Cada una con su ajuste de máximo esfuerzo.
| Herramienta | Bytes | vcompresor deja |
|---|---|---|
| zip -9 | 30.705.489 | 73,1 % menos |
| gzip -9 | 24.619.040 | 66,4 % menos |
| WinRAR -m5 sólido, dicc. 512 MB | 16.246.830 | 49,1 % menos |
| Zstandard -19 --long | 13.465.136 | 38,6 % menos |
| vcompresor — modo por defecto | 13.415.749 | el carril rápido |
| brotli -q 11 | 13.155.365 | 37,2 % menos |
| 7-Zip -mx9 | 12.761.603 | 35,2 % menos |
| xz -9e | 12.751.136 | 35,2 % menos |
| lrzip -z | 11.516.022 | 28,2 % menos |
| zpaq -m5 | 9.744.091 | 15,2 % menos |
vcompresor --max | 8.266.736 | — |
A los compresores de flujo (gzip, Zstandard, brotli, xz, lrzip) se les dio el mismo tar de 149.452.800 bytes; los archivadores (zip, WinRAR, 7-Zip, zpaq, vcompresor) trabajaron directamente sobre el árbol. Sólo se comparan bytes: son deterministas y no dependen de la carga de la máquina.
de compresión sobre el corpus entero
herramientas batidas, sin una sola excepción
dependencias externas en el motor
Y también en Silesia, el corpus público de referencia
Silesia son doce ficheros sueltos y en buena parte binarios: nada se repite entre ellos, así que la deduplicación no vale de nada y el reordenado por parecido tampoco. Es sólo el modelo contra el modelo, y aun así gana.
Aquí el margen es estrecho a propósito de contarlo: un 0,14% sobre zpaq. Lo que importa de esta tabla no es el margen, es que en el terreno donde nuestras ventajas de archivador valen cero seguimos delante — y a 7-Zip y a xz les sacamos 18 puntos.
| Herramienta | Bytes | Ratio |
|---|---|---|
vcompresor --max | 39.809.371 | 18,78 % |
| zpaq -m5 | 39.865.426 | 18,81 % |
| 7-Zip -mx9 | 48.715.234 | 22,99 % |
| xz -9 | 48.776.804 | 23,01 % |
Verificado extrayendo el archivo entero y comparando con el original: cero diferencias en los doce ficheros, y en los 27.804 del corpus real — incluidos enlaces simbólicos, permisos, fechas y directorios vacíos.
A quién no le ganamos
Esto importa tanto como la tabla de arriba. Una comparativa en la que uno gana siempre y no dice dónde pierde no es una comparativa: es un anuncio.
paq8px y cmix nos ganan en ratio
Sobre muestras pequeñas de texto, paq8px nos saca un 21,9 %. Es el techo conocido de la compresión determinista y no lo escondemos. El precio que paga: 0,008 MB/s y 2,4 GB de memoria — unas 125 veces nuestro tiempo. No son productos: existen para ganar concursos de compresión, no para archivar el disco de nadie.
El máximo ratio se paga en tiempo
El modo --max es varias veces más lento que zpaq, y esa es la frontera en la que estamos trabajando. Por eso el producto trae dos carriles: el modo por defecto va muy rápido y ya le gana a WinRAR y a Zstandard, y --max es para cuando lo que cuesta dinero es el disco y no la CPU.
Vídeo y audio, no
No hay carril para H.264, AAC ni MP3. Un códec especializado nos gana en su terreno, y sobre material ya comprimido de ese tipo el archivo saldrá prácticamente del mismo tamaño.
.rar y .7z van tal cual
Deshacemos DEFLATE y JPEG, pero no RAR ni LZMA: esos se guardan literales con un 0,01 % de sobrecoste. Si vas a archivarlos, desempaquétalos antes y la diferencia es enorme.
Cuándo un 35% menos cambia la factura
Un 35% menos de bytes no es una curiosidad técnica cuando lo que guardas se mide en terabytes y se paga cada mes.
Copias de seguridad y archivo frío
Lo que se guarda una vez y se lee casi nunca es exactamente donde --max tiene sentido: se paga CPU una vez y se ahorra disco todos los meses.
Cumplimiento y archivo verificable
La salida byte-idéntica entre arquitecturas permite firmar el archivo y volver a producir el mismo SHA-256 años después, en otra máquina y con otro procesador.
Repositorios, registros y volcados
Código, logs y volcados de base de datos son el terreno donde más margen sacamos: mucha estructura repetida y muchos ficheros parecidos entre sí.
¿Cuánto ocuparían tus datos?
Lo medimos sobre una muestra tuya y te decimos el número exacto, no una estimación. Si no compensa, te lo decimos igual.
Pedir una mediciónLicencia dual: AGPL para uso abierto, licencia comercial para producto cerrado.