Base64 explicado: Cómo funciona, cuándo usarlo y cuándo no

Base64 aparece en archivos adjuntos de correo electrónico, JSON Web Tokens, URL de datos, secretos de Kubernetes, autenticación HTTP Basic e innumerables API que necesitan mover datos binarios a través de canales de solo texto. Es simple una vez que ves cómo funciona, sin embargo, a menudo se usa mal sobre todo como si se tratara de cifrado. Este artículo explica el algoritmo paso a paso, las variantes comunes y una guía práctica sobre cuándo Base64 es la herramienta correcta.

El problema que resuelve Base64

Muchos sistemas fueron diseñados para transportar texto, no bytes arbitrarios. El correo electrónico (SMTP) históricamente soportaba solo ASCII de 7 bits. Las cadenas JSON no pueden contener binario en bruto. URL y encabezados HTTP tienen conjuntos de caracteres restringidos. Si pones los bytes en bruto de una imagen en cualquiera de estos, algunos bytes serán interpretados como caracteres de control, terminaciones de línea o delimitadores, y los datos se corrompen.

Base64 asigna bytes arbitrarios a 64 caracteres seguros e imprimibles: A–Z, a–z, 0–9, + y /. Cualquier sistema que pueda transportar texto plano puede entonces transportar los datos intactos.

Cómo funciona la codificación

Base64 procesa la entrada en grupos de 3 bytes (24 bits) y sacan 4 caracteres de 6 bits cada uno. Dado que 2 ^ 6 = 64, cada valor de 6 bits selecciona un carácter del alfabeto.

Toma la palabra Man:

1. Los bytes ASCII: M = 77, a = 97, n = 110.
2. En binario: 01001101 01100001 01101110.
3. Dividido en cuatro grupos de 6 bits: 010011 010110 000101 101110.
4. Como números: 19, 22, 5, 46.
5. Busca en el alfabeto: T, W, F, u.

Así que Man se convierte en TWFu. La decodificación invierte el proceso.

Revestimiento con =

Cuando la longitud de entrada no es un múltiplo de 3, el último grupo es incompleto. Base64 lo cubre:

• 1 byte restante produce 2 caracteres más ==.
• 2 bytes restantes producen 3 caracteres más =.

Ma codifica a TWE= y M a TQ==. El relleno hace que la longitud de salida sea un múltiplo de cuatro, que algunos decodificadores requieren. Otros, especialmente las implementaciones seguras de URL, lo omiten porque la longitud ya implica cuántos bytes faltan.

Tamaño de los gastos generales

Cada 3 bytes se convierten en 4 caracteres, por lo que la salida de Base64 es aproximadamente un 33% más grande que la entrada, además de relleno y a veces interrupciones de línea (el correo electrónico MIME envuelve líneas a 76 caracteres). Una imagen de 1 MB se convierte aproximadamente en 1,37 MB de texto. Eso es importante cuando se incrustan archivos grandes en JSON o HTML.

Base64 con seguridad de URL

El alfabeto estándar incluye + y /, que tienen significados especiales en las URL, y = que se utiliza en las cadenas de consulta. Base64URL, definido en RFC 4648, reemplaza + por - y / por _, y generalmente elimina el relleno. JWT, muchos tokens de API y teclas push web utilizan esta variante ver cómo funciona JWT como ejemplo.

Un decodificador estándar falla en - y _, y viceversa, que es una fuente común de errores de "caracteres inválidos". Un decodificador de base64 tolerante acepta ambos alfabetos y restaura el relleno perdido automáticamente.

Texto, bytes y Unicode

Base64 codifica bytes, no caracteres. Para codificar texto, primero debe convertirlo a bytes con una codificación de caracteres, casi siempre UTF-8. Aquí es donde los navegadores hacen tropezar a la gente: el btoa() integrado en JavaScript acepta solo caracteres en el rango de latín-1, por lo que btoa("héllo") funciona por accidente y btoa("你好") arroja un error.

El enfoque correcto en JavaScript moderno:

const bytes = new TextEncoder().encode("你好 👋");
const b64 = btoa(String.fromCharCode(...bytes));
const back = new TextDecoder().decode(Uint8Array.from(atob(b64), c => c.charCodeAt(0)));

Otros lenguajes lo hacen explícito: Python base64.b64encode toma bytes, así que escribe base64.b64encode("你好".encode("utf-8")).

Direcciones URL de los datos

Una URL de datos incrusta un archivo directamente en HTML o CSS:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." alt="">

Esto salva una solicitud HTTP, que era valiosa en la era HTTP/1.1. Hoy en día, con el multiplexado HTTP/2, las compensaciones generalmente favorecen archivos separados:

• Las URL de datos no se pueden almacenar en caché de forma independiente; se vuelven a descargar con cada página o hoja de estilo que las contiene.
• Inflan HTML y CSS, lo que bloquea el renderizado hasta que se descargan y analizan.
• El 33% de gastos generales se aplica, aunque gzip recupera parte de él.

Utilice URL de datos para activos pequeños iconos pequeños de menos de 1 2 KB, imágenes de marcadores de posición o exportaciones HTML de un solo archivo. Para algo más grande, sirve un archivo normal y comprimirlo en su lugar.

Base64 no es cifrado

Este es el punto más importante. Base64 no tiene llave. Cualquiera puede descifrarlo al instante, y muchas herramientas lo hacen automáticamente. Sin embargo, es común encontrar:

• Las claves de la API están "ocultas" en Base64 en el código front-end.
• Las contraseñas almacenadas en base64 codificadas en bases de datos o archivos de configuración.
• Se supone que los secretos de Kubernetes están protegidos porque sus valores son Base64.

Kubernetes codifica valores secretos en Base64 puramente para que los datos binarios encajen en YAML; la protección proviene del control de acceso y el cifrado en reposo, que deben configurarse por separado. Si los datos necesitan ser confidenciales, cifrar con un algoritmo real como AES-GCM, y si usted necesita verificar las contraseñas, utilizar una función de hash de contraseña no Base64 y no un simple hash como MD5 (por qué no).

Casos de uso comunes hechos bien

• ** Autenticación básica HTTP** envía Authorization: Basic base64(user:password). La codificación solo evita problemas con caracteres especiales; las credenciales están protegidas únicamente por HTTPS.
• ** Los archivos adjuntos de correo electrónico** utilizan MIME Base64 con interrupciones de línea cada 76 caracteres.
• La incorporación de datos binarios en JSON, como una pequeña imagen de firma o una clave criptográfica, es un uso legítimo. Para archivos grandes, cargue por separado y haga referencia a ellos por URL.
• ** Almacenamiento de datos binarios en configuración de solo texto**, como certificados TLS en variables de entorno.

Solución de errores de decodificación

• Caracteres no válidos: probablemente está decodificando Base64URL con un decodificador estándar, o la cadena contiene espacios en blanco o pausas de línea.
• ** Revestimiento incorrecto:** añadir = hasta que la longitud sea múltiple de cuatro.
• Texto distorsionado después de la decodificación: el original fue codificado desde un conjunto de caracteres diferente, o los datos son binarios en lugar de texto.
• ** La salida parece Base64 otra vez:** los datos fueron codificados dos veces; decodificar una vez más.

Códigos relacionados

• Base32 utiliza 32 caracteres (AZ y 27), es insensible a mayúsculas y minúsculas y se utiliza en secretos TOTP para aplicaciones de autenticación. Los gastos generales son del 60%.
• Hexadecimal (Base16) utiliza dos caracteres por byte 100% de sobrecarga pero es fácil de leer y común para hashes.
• Base58 elimina caracteres similares y se utiliza en las direcciones de Bitcoin.
• %-encoding escapa sólo caracteres inseguros en las URL.

Resumen

Base64 convierte bytes a un alfabeto de texto de 64 caracteres, 3 bytes a la vez, a un costo de aproximadamente 33% de tamaño adicional. Utilizarlo para transportar datos binarios a través de canales de texto; utilizar la variante segura de URL en URL y tokens; siempre convertir el texto a bytes UTF-8 primero. Nunca lo uses para proteger secretos es una codificación, no una cerradura.