Comprimir archivos antes de enviar: reduce tamaño y tiempo

Comprime texto, código fuente, logs, CSV e imágenes sin comprimir como .bmp o .tiff antes de enviar: espera reducciones de 3-10x en el tamaño. No comprimas .jpg, .png, .mp4, .mp3, .docx, .xlsx, .pdf ni .zip: ya están comprimidos internamente y una segunda pasada aporta como mucho un 2-3% de ahorro mientras consume CPU. Para agrupar muchos archivos pequeños en una sola subida, usa .zip en modo almacenamiento (sin compresión). Para máximo ratio en datos comprimibles, 7z con LZMA2 supera habitualmente al .zip en un 30-40%. El RAR es equivalente a 7z en términos de ratio, pero requiere que el receptor tenga WinRAR o 7-Zip instalado: el .zip tiene compatibilidad universal.

Cuándo la compresión realmente ayuda

Los archivos de texto se comprimen de forma espectacular. Un archivo .log de servidor de 10 MB suele reducirse a 800 KB con .zip (12x) y a 550 KB con 7z (18x). La compresión funciona porque los logs contienen patrones muy repetitivos: marcas de tiempo, direcciones IP, códigos de estado HTTP, que los algoritmos de compresión explotan de forma eficiente.

Categorías igualmente comprimibles:

Código fuente: .js, .py, .java, .cs, .go — compresión típica de 3-5x
Datos CSV: 4-10x según la redundancia del contenido
JSON/XML: 5-8x por los nombres de campo repetidos
Imágenes sin comprimir: .bmp (5-10x), .tiff sin comprimir (4-8x)
Bases de datos: volcados .sql, archivos SQLite con páginas libres (2-4x)
PSD con capas planas: 2-3x si no están ya comprimidas internamente con RLE

Un tarball de un repositorio Git de tamaño mediano suele comprimirse 4-5x, por eso git archive envuelve el árbol en .tar.gz por defecto.

Cuándo la compresión es inútil

Los formatos ya comprimidos no se hacen más pequeños. Los datos subyacentes ya han pasado por DEFLATE, H.264, cuantización DCT de JPEG u un esquema similar: la entropía ya está cerca del mínimo teórico.

Archivos que no se benefician:

.jpg, .jpeg, .heic: compresión con pérdida ya aplicada
.png: compresión DEFLATE integrada
.mp4, .mov, .mkv: compresión H.264 o H.265 ya aplicada
.mp3, .aac, .flac, .ogg: audio ya comprimido
.pdf: los flujos de objetos internos suelen estar comprimidos con DEFLATE
.docx, .xlsx, .pptx: son archivos ZIP de XML: volver a comprimir es redundante
.zip, .7z, .rar, .gz, .bz2, .xz: archivos comprimidos; otra pasada es inútil
.apk, .jar, .war: archivos Java/Android basados en ZIP

Comprimir estos archivos desperdicia CPU y a veces incluso agranda el archivo por la sobrecarga de metadatos del archivo.

ZIP vs 7z vs RAR

| Formato | Ratio típico | Velocidad | Compatibilidad con receptor | Encriptación | |---|---|---|---|---| | .zip (DEFLATE) | Referencia | Rápida | Universal (integrado en Windows, macOS, Linux) | ZIP 2.0 (débil), AES-256 (herramientas modernas) | | .zip (DEFLATE64) | 5-10% mejor | Rápida | Windows nativo, 7-Zip, algunas herramientas macOS | Igual que .zip | | 7z (LZMA2) | 30-40% mejor que .zip | Más lenta | Requiere 7-Zip, Keka o The Unarchiver | AES-256 integrado | | .rar (RAR5) | ~25-35% mejor que .zip | Media | Requiere WinRAR o 7-Zip; crear no es gratuito | AES-256 integrado | | .tar.gz | Similar a .zip | Rápida | Integrado en macOS, Linux; necesita 7-Zip en Windows | Sin cifrado nativo | | .tar.zst (Zstandard) | Entre .zip y 7z | Muy rápida | Requiere zstd (no universal aún) | Sin cifrado nativo |

Para portabilidad, .zip sigue siendo la elección más segura. Para ratio, 7z gana. Para velocidad y eficiencia moderna, Zstandard (.zst) es excelente, pero los receptores necesitan herramientas que lo soporten.

Modo "almacenamiento" para agrupar archivos

Si envías 200 fotos .jpg en una sola transferencia, quieres que estén en un único archivo para que el receptor haga clic en "descargar" una sola vez. Usa .zip con nivel de compresión 0 (modo "almacenamiento"). El archivo es la suma de los tamaños de los archivos más unos pocos kilobytes de directorio: el coste de CPU para crearlo es casi cero.

En 7-Zip: Añadir al archivo → Nivel de compresión → Almacenar. En macOS Finder: clic derecho → Comprimir (usa DEFLATE por defecto, que no ayudará en .jpg pero no perjudica mucho). En la línea de comandos: zip -0 bundle.zip *.jpg.

Encriptación al comprimir

Los archivos ZIP protegidos con contraseña usando AES-256 (no el obsoleto cifrado ZIP 2.0) son una opción razonable de transporte para datos sensibles cuando no puedes confiar en la seguridad del canal de transferencia. WinRAR, 7-Zip y Archive Utility de macOS admiten cifrado AES-256 en ZIP.

El problema: el intercambio de contraseñas. No envíes la contraseña en el mismo mensaje que el ZIP. Envía el archivo y comparte la contraseña por Signal, iMessage u otro canal separado. Mejor aún: usa un servicio de transferencia con protección por contraseña integrada, que gestiona la complejidad por ti.

El cifrado ZIP 2.0 heredado (todavía predeterminado en algunas herramientas antiguas) está criptográficamente roto: se puede recuperar en segundos con ataques de texto conocido. Siempre verifica que estás usando AES-256 si confías en el cifrado de archivos para la seguridad. Esta distinción es especialmente relevante bajo el RGPD, donde la protección de datos personales tiene requisitos técnicos concretos.

Compromiso: tiempo de CPU vs bytes ahorrados

La compresión es un equilibrio entre tiempo y tamaño. La compresión máxima de 7z en un archivo de texto de 5 GB puede tardar 30 minutos en un portátil y ahorrar 2 GB respecto al .zip. Si la transferencia está limitada por tamaño (un servicio con un techo de 2 GB), vale la pena. Si la transferencia está limitada por tiempo y el ancho de banda es barato, los mismos 5 GB se suben en 90 segundos por fibra: la media hora de compresión habría costado más tiempo del que ahorró.

Heurística: comprime cuando la red es lenta en relación a la CPU; no te molestes cuando la red es rápida en relación a la CPU.

División de archivos grandes

Cuando un archivo supera el techo de un servicio de transferencia, dividirlo en volúmenes es una opción. 7-Zip y WinRAR soportan archivos en múltiples partes (.7z.001, .7z.002, o .part1.rar, .part2.rar). Cada parte se puede subir como una transferencia separada; el receptor descarga todas las partes y las extrae.

Funciona pero es frágil: si falta una sola parte, el archivo completo es inutilizable. Mejor cuando sea posible: usa un servicio con un techo mayor. El límite de 50 GB de SwissTransfer elimina la necesidad de dividir en la mayoría de los casos reales.

La compresión con pérdida como alternativa

A veces el objetivo no es la compresión del archivo, sino la compresión del formato. Un archivo de audio .wav de 200 MB se convierte en un .mp3 de 320 kbps de 15 MB: con pérdida pero casi transparente para la escucha casual. Una foto .tiff sin comprimir de 60 MB se convierte en un .jpg de alta calidad de 5 MB. Un vídeo .mov en 4K recodificado a H.265 con una tasa de bits razonable puede reducirse 3-5x.

Úsala con criterio. Para archivos maestros, la conversión con pérdida destruye información. Para previsualizaciones o entregables, es la herramienta adecuada. Herramientas: FFmpeg para vídeo/audio, Handbrake para vídeo, ImageMagick para imágenes, y los cuadros de diálogo de exportación en Photoshop, Final Cut Pro o Premiere.

Lo que hace el servicio de transferencia de todos modos

La mayoría de los servicios de transferencia comprimen un poco durante el tránsito: la compresión TLS está desactivada por razones de seguridad, pero gzip o brotli en HTTP en la capa de API interviene ocasionalmente en los metadatos. El payload del archivo en sí no se comprime en el servidor porque la mayoría del tráfico ya está en formatos comprimidos.

HexaTransfer y servicios similares de conocimiento cero no pueden comprimir payloads en el servidor porque reciben texto cifrado. La compresión debe realizarse en el cliente antes del cifrado: después del cifrado, el texto cifrado tiene aspecto aleatorio y es incompresible. Esto significa que la compresión en el cliente es la única forma de reducir el tamaño al usar un servicio E2EE.

Decide según el contenido, no por hábito

El principal error es el "siempre comprimir antes de enviar" reflexivo. Para un cliente que recibe 20 documentos .pdf, un ZIP agrupado es conveniente. Para un cliente que recibe un único .mp4 de 800 MB, el ZIP desperdicia tiempo en ambos lados. Adapta la elección al contenido.

En caso de duda: envía en bruto. El receptor siempre puede comprimir después de recibir. Si agrupas múltiples archivos, usa .zip en modo almacenamiento. Si el contenido es mayormente texto, usa 7z para un ahorro real.

Conclusión

Comprime cuando los datos son comprimibles: texto, logs, código fuente, bases de datos. No comprimas cuando los datos ya están comprimidos: fotos, vídeos, audio, PDF, documentos de Office. Para agrupar, usa ZIP en modo almacenamiento. Para máximo ratio en texto, usa 7z con LZMA2. Encripta con contraseñas de archivo AES-256 solo como complemento a un canal de transferencia seguro, no como sustituto.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.