Qué es Base64: codificación, no cifrado

Qué hace Base64

El RFC 4648 define Base64 como una forma de representar secuencias arbitrarias de bytes con un formato que admite mayúsculas y minúsculas y que no tiene por qué ser legible por personas. Usa un subconjunto de 65 caracteres de US-ASCII: 64 para llevar datos (A–Z, a–z, 0–9, + y /), suficientes para representar 6 bits cada uno, más = para el relleno.

El proceso toma la entrada de tres en tres bytes (24 bits), los divide en cuatro grupos de 6 bits y convierte cada uno en un carácter. Esa es toda la idea, y explica los dos hechos que todos deberían conocer: el resultado se compone solo de caracteres imprimibles y es aproximadamente un tercio mayor que la entrada, porque 3 bytes pasan a ser 4 caracteres. Diez bytes se convierten en 16 caracteres, 1.000 bytes en 1.336 y 3 MB en 4 MB.

Un ejemplo corto: el texto Ana:clave se codifica como QW5hOmNsYXZl. Pégalo en el codificador y decodificador de Base64 y recuperas el original, que es justo la idea.

No es cifrado

Este es el malentendido con consecuencias. Base64 no tiene clave ni secreto: decodificar es un paso mecánico que cualquiera puede hacer. Se usa para hacer los datos transportables, no privados. Si una contraseña, un token o un documento están «protegidos» solo con Base64, no están protegidos.

La autenticación «Basic» de HTTP muestra cómo se traduce esto. Envía el nombre de usuario y la contraseña unidos por dos puntos y codificados en Base64. El RFC 7617 afirma con claridad que ese esquema no es un método seguro de autenticación salvo que se use con algo como TLS, porque el usuario y la contraseña viajan por la red en claro. Base64 ahí es solo un envoltorio cómodo, y la seguridad la pone (o no) HTTPS. Lo mismo vale para la carga de un JWT, que está codificada en base64url y la puede leer cualquiera que tenga el token (mira cómo leer un JWT).

Dónde te lo vas a encontrar

• Adjuntos de correo. El correo se diseñó para texto; los archivos se codifican en Base64 (MIME) para viajar dentro del mensaje. Es una de las razones de que un adjunto añada más o menos un tercio al tamaño en la red.
• URI de datos. Las imágenes pequeñas incrustadas directamente en HTML o CSS tienen el aspecto data:image/png;base64,iVBOR…. Cómodo para iconos diminutos, poco eficiente para imágenes grandes por el tercio extra y porque no se pueden guardar en caché por separado.
• JSON y API. JSON no tiene un tipo binario, así que archivos y claves se envían a menudo como cadenas Base64.
• Tokens y claves. Los JWT, los certificados en formato PEM y muchas claves de API usan Base64 o su variante para URL.

El relleno: por qué a veces hay un =

La entrada llega en grupos de tres bytes. Cuando el último grupo solo tiene uno o dos bytes, la salida se rellena con signos = para que su longitud sea múltiplo de 4: un byte sobrante da dos =, dos bytes sobrantes dan uno. El relleno no lleva información; solo dice al decodificador cuántos bytes tenía el último grupo. El RFC 4648 indica que cuando la longitud de los datos se conoce de antemano el relleno se puede omitir, y es lo que suele hacer base64url.

Base64url: la variante para URL

Los caracteres + y / tienen significado especial en las URL y los nombres de archivo. La sección 5 del RFC 4648 define una variante que los sustituye por - y _, y dice que debe llamarse «base64url» y no solo «base64». La usan los JWT. Confundirlas es una fuente habitual de errores al decodificar: una cadena base64url que se pasa a un decodificador normal falla en cuanto encuentra un - o un _. Por ejemplo, los tres bytes 251, 255, 254 se codifican como +//+ en Base64 y como -__- en base64url.

El problema de las tildes (btoa y atob)

Base64 codifica bytes, no texto, así que importa cómo se convierte el texto en bytes. En los navegadores, btoa() trata cada carácter como un byte, lo que solo funciona con puntos de código menores de 256. MDN documenta que pasar un carácter que no cabe en un byte lanza un InvalidCharacterError (prueba btoa("€")). Y aunque no falle, puedes obtener un resultado distinto del de otras herramientas: btoa("Mañana") da TWHxYW5h, porque la «ñ» se trata como el byte único 0xF1, mientras que un codificador UTF-8 da TWHDsWFuYQ==, con la «ñ» como dos bytes. Cuando intercambies texto en Base64 con otros sistemas, lo correcto casi siempre es convertir primero el texto a bytes UTF-8 y codificar después. La herramienta de arriba lo hace así.

Errores habituales al decodificar

• Carácter o longitud no válidos: espacios, saltos de línea o un carácter que falta al copiar y pegar. Algunos decodificadores toleran los espacios en blanco y otros no.
• Alfabeto equivocado: una cadena para URL (-, _) enviada a un decodificador estándar, o al revés.
• Relleno ausente: algunos decodificadores exigen los =; añádelos hasta que la longitud sea múltiplo de 4.
• Texto deformado tras decodificar: los bytes se decodificaron bien, pero se leyeron con el juego de caracteres equivocado. Si el original era UTF-8, léelo como UTF-8.

Fuentes y más información

• RFC 4648: The Base16, Base32, and Base64 Data Encodings
• RFC 7617: The 'Basic' HTTP Authentication Scheme
• MDN: Window.btoa() (cadenas Unicode)

Datos comprobados el 3 de octubre de 2026.