¿Por qué Base64 hace los archivos más grandes?

Este artículo explica por qué la salida Base64 es más grande que los bytes originales. No es una guía de seguridad. Si necesitas codificación frente a cifrado, usa Base64 no es cifrado: qué hace realmente y cómo decodificarlo.

¿Por qué Base64 necesita más espacio?

3 bytes son 24 bits. Base64 parte esos 24 bits en 4 grupos de 6 bits. Cada grupo se asigna a un carácter Base64, así que 3 bytes de entrada pasan a 4 caracteres de salida. Guardado como 1 byte por carácter ASCII, eso es 4 / 3 ≈ 1.333 — un aumento de unos 33.3%.

• 3 bytes (24 bits)
• ↓
• Partir en 4 grupos de 6 bits
• Cada grupo → un carácter Base64
• ↓
• 4 caracteres (a menudo 4 bytes de texto)

Un ejemplo simple y comprobable

Estas codificaciones coinciden con Base64 rellenado estándar.

Man

Man

Base64

TWFu

Man son 3 bytes UTF-8/ASCII. TWFu son 4 caracteres: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello son 5 bytes. SGVsbG8= son 8 caracteres, incluido un =. En datos pequeños, el relleno hace que el porcentaje parezca mayor que 33%.

¿Cómo se calcula el tamaño de Base64?

Para Base64 rellenado estándar, encodedLength = 4 × ceil(originalBytes / 3).

Bytes originales	Caracteres Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 o 2 bytes siguen produciendo 4 caracteres. Usa la fórmula, no un 33% fijo.

¿Qué significa el relleno «=»?

La marca = indica que el último bloque de 3 bytes no estaba completo. 1 byte de entrada usa dos caracteres =; 2 bytes usan uno; 3 bytes no usan ninguno. El relleno no es cifrado ni una función de seguridad.

¿Base64URL usa menos espacio?

Base64URL cambia + por - y / por _, y Codificar y decodificar Base64 omite los = finales al codificar. Eso puede acortar la cadena en esos caracteres =. La estructura de 3 bytes → 4 caracteres se mantiene, así que Base64URL no es un formato binario más eficiente en espacio.

¿Por qué las entradas minúsculas pueden crecer más del 33%?

1 byte → 4 caracteres es un aumento del 300% en longitud. 2 bytes → 4 es 100%. 3 bytes → 4 es unos 33.3%. Conforme n crece, el relleno importa menos y el coste extra se acerca a unos 33%. Base64 no es un 33% más grande en todos los casos.

¿Por qué una Data URL Base64 es aún más grande?

Una Data URL añade un prefijo como data:image/png;base64, delante de la carga. En un archivo minúsculo ese prefijo puede dominar el porcentaje. Codificar y decodificar Base64 puede emitir Base64 crudo o una Data URL; la salida Data URL usa el alfabeto estándar.

Base64 frente a binario: ¿cuál es más pequeño?

El binario crudo es más eficiente en espacio para transporte y almacenamiento. Base64 es más grande, pero seguro como texto en JSON, correo y otros caminos solo texto. Es codificación de binario a texto, no compresión.

¿Base64 comprime archivos?

No. Base64 no es un formato de compresión. El texto codificado suele ser más grande que los bytes originales. Si luego aplicas gzip o Brotli a ese texto, parte de la redundancia puede encogerse — el resultado depende de los datos y del compresor. gzip no elimina por completo el coste extra de Base64.

¿Qué ocurre si se aplica gzip a Base64?

La compresión HTTP puede reducir algunos patrones repetidos en texto Base64. JPEG, PNG o ZIP suelen comprimir mal incluso como bytes crudos, y Base64-luego-gzip sigue dependiendo del caso. No hay un porcentaje extra universal después de gzip.

¿Deberías guardar archivos como Base64?

Base64 puede meter binario en un campo JSON, un recurso pequeño en línea, una API solo texto, copiar y pegar o una Data URL. En archivos grandes, almacenamiento, memoria y tamaño de carga crecen. Eso no es «nunca uses Base64 para archivos».

¿Por qué Base64 es habitual en APIs JSON?

JSON no tiene un tipo nativo de binario crudo, así que las APIs suelen poner bytes en una cadena Base64. Para archivos grandes, multipart/form-data, almacenamiento de objetos o una subida binaria directa pueden encajar mejor. Ninguna opción es siempre la mejor.

¿Por qué se usa Base64 en el correo?

MIME puede usar Base64 para que un adjunto binario viaje como caracteres seguros para texto. El mismo coste extra de tamaño sigue aplicando. Es una representación de transporte, no un archivo más pequeño.

¿Cuándo merece la pena el tamaño extra?

El tamaño extra puede merecer la pena cuando el binario debe ir dentro de texto, la carga es pequeña, una API exige Base64 o necesitas una Data URL. Para medios grandes, prefiere binario crudo cuando el sistema lo permite.

¿Cuándo deberías evitar Base64?

Evítalo en archivos grandes, ancho de banda ajustado, transferencias frecuentes o cuando ya existe un camino binario — situacional, no «Base64 es mala práctica».

Longitudes de Base64 rellenado que puedes comprobar

Recuentos de bytes originales y recuentos de caracteres Base64 rellenado estándar:

Bytes originales	Caracteres Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Todas las filas siguen 4 × ceil(n / 3). Son recuentos de caracteres Base64.

Ejemplo: ¿de qué tamaño será un archivo de 1,000 bytes?

4 × ceil(1000 / 3). ceil(333.333…) = 334, y 4 × 334 = 1336. Así que 1,000 bytes pasan a 1,336 caracteres Base64. Guardados como UTF-8/ASCII, cada carácter suele ser 1 byte — no trates 1,336 como un recuento exacto de bytes en memoria.

¿Puede Base64 usar más memoria de la que sugiere el tamaño del archivo?

Algunos entornos guardan cadenas con más de 1 byte por carácter, y codificar/decodificar puede mantener un búfer y una cadena a la vez. El uso de memoria no es exactamente la longitud en caracteres.

Una guía simple para decidir por el tamaño

Si el sistema acepta binario crudo, prefiérelo por tamaño. Si solo se permite texto, Base64 puede encajar. Para una carga grande, busca un camino de subida binaria. Para texto seguro en URL, considera Base64URL — la expansión de 3 a 4 se mantiene.

• Hay que enviar datos binarios
• ↓
• ¿Se permite binario crudo? Prefiere binario por tamaño
• ¿Campo solo texto? Base64 puede ser adecuado
• ¿Carga grande? Busca un camino de subida binaria
• ¿Necesitas texto seguro para URL? Considera Base64URL
• ↓
• Espera unos 33% más de texto en entradas grandes

Codifica o decodifica Base64 en tu navegador

NEXNARA Codificar y decodificar Base64 codifica y decodifica texto, y puede convertir un archivo en Base64 o una Data URL y devolver Base64 a un archivo.

El texto usa bytes UTF-8 y luego Base64 — no solo ASCII. Elige Standard o Base64URL. La salida de archivo puede ser Base64 crudo o una Data URL (alfabeto estándar). La entrada inválida se rechaza. Los bytes que no son UTF-8 necesitan ir a archivo, no decodificarse como texto.

Los archivos de más de 10 MB pueden ralentizar la pestaña (aviso). Los archivos de más de 32 MB se bloquean.

La codificación y la decodificación ocurren en tu navegador. El archivo no se envía a un servidor de NEXNARA para esta herramienta. Los anuncios y otras funciones del sitio siguen usando la red.

Pega texto o un archivo en Codificar y decodificar Base64 y compara los bytes originales con la longitud codificada.

FAQ

¿Por qué Base64 aumenta el tamaño del archivo?

Mapea 3 bytes (24 bits) a 4 caracteres (4 × 6 bits). Guardado como texto, eso es alrededor de un tercio más en entradas grandes.

¿Base64 es siempre un 33% más grande?

No. Las entradas grandes se acercan a unos 33.3%. Las entradas minúsculas pueden crecer más por el relleno. Usa 4 × ceil(n / 3).

¿Cuánto más grande es Base64 que el binario?

La longitud rellenada estándar es 4 × ceil(n / 3) caracteres. Un prefijo de Data URL añade más.

¿La compresión Base64 reduce el tamaño del archivo?

Base64 no comprime. gzip o Brotli sobre el texto codificado pueden encoger una parte; no borran el coste extra en todos los casos.

¿Base64URL usa menos espacio?

Puede omitir el relleno =, así que la cadena puede ser 0–2 caracteres más corta. La estructura de codificación de 3 a 4 es la misma.

¿Debo usar Base64 para archivos grandes?

Solo si necesitas texto. Para transferencias grandes o frecuentes, un camino binario suele ser más pequeño. Base64 no es siempre incorrecto en APIs.