En resumen
Base64 es una forma de escribir cualquier secuencia de bytes con 64 caracteres seguros (A–Z, a–z, 0–9, +, /). Existe para que los datos binarios (una imagen, un PDF, una clave) puedan viajar por sistemas que solo manejan texto: cuerpos de correo electrónico, cadenas JSON, URL, atributos HTML. Es una codificación, no un cifrado: no hay clave, y decodificarlo es una sola llamada a una función disponible en todos los lenguajes y en la consola de desarrollo de cualquier navegador. Una contraseña guardada “en Base64” está guardada en texto plano con pasos de más.
Por qué existe
El correo electrónico se diseñó en los años setenta para ASCII de 7 bits. Cuando llegaron los adjuntos (MIME, 1992), los bytes de un JPEG, que usan los 256 valores posibles, incluidos algunos que para un servidor de correo significan “fin de línea” o “fin de mensaje”, tenían que disfrazarse de texto inofensivo. La respuesta fue Base64: tomar tres bytes (24 bits), dividirlos en cuatro grupos de 6 bits y asignar a cada grupo uno de 64 caracteres. Cada 3 bytes se convierten en 4 caracteres, y de ahí sale la famosa sobrecarga del 33 %: un adjunto de 3 MB es un correo de 4 MB, y por eso en un límite de “25 MB” cabe un archivo de 18 MB.
El mismo truco aparece allí donde el texto es el único canal: incrustar una imagen pequeña directamente en una página web (data:image/png;base64,…), meter un token binario en una cabecera HTTP (Authorization: Basic …), transportar certificados y claves en archivos PEM o guardar un array de bytes en un campo JSON.
Las variantes que confunden
- Estándar frente a URL-safe. El Base64 estándar usa
+y/, y los dos tienen significado en una URL. El alfabeto URL-safe (RFC 4648 §5) los sustituye por-y_. Un token generado con uno y decodificado con el otro falla en esos dos caracteres. Los JWT usan la forma URL-safe. - Relleno. La longitud de la salida siempre es múltiplo de cuatro y se completa con
=. Algunos generadores eliminan el relleno (otra vez los JWT) y algunos decodificadores lo exigen. Si una cadena por lo demás válida no se decodifica, prueba a añadir=hasta que la longitud sea divisible entre cuatro. - Saltos de línea. MIME corta las líneas a 76 caracteres; PEM, a 64. Los decodificadores suelen ignorar los espacios en blanco, aunque no todos.
- La codificación de texto de debajo. Base64 codifica bytes. Para pasar una cadena a Base64 primero hay que convertirla en bytes, y elegir UTF-8, UTF-16 o Latin-1 cambia el resultado. El error clásico de JavaScript, que
btoa("é")lance una excepción, es exactamente esto:btoasolo acepta Latin-1. Primero hay que codificar a bytes UTF-8.
La herramienta Base64 maneja los dos alfabetos, el relleno, los saltos de línea y UTF-8, y decodifica a texto o a un archivo descargable, así que una URL data: o un adjunto de correo pueden volver a su forma original en el navegador.
Codificar, hashear, cifrar
Estas tres palabras se usan como sinónimos en textos informales y significan cosas completamente distintas.
| ¿Reversible? | ¿Necesita clave? | Finalidad | |
|---|---|---|---|
| Codificación (Base64, hexadecimal, codificación URL) | Sí, por cualquiera | No | Adaptar los datos a un canal |
| Hash (SHA-256, MD5) | No | No | Obtener la huella de los datos; comprobar que no se han modificado |
| Cifrado (AES, RSA) | Sí, con la clave | Sí | Mantener los datos en secreto para quien no tenga la clave |
El hash de un archivo permite comprobar que una descarga coincide con lo que publicó el autor: el Generador de hash calcula MD5, SHA-1 y SHA-256/384/512 en el navegador y lo compara con una suma de comprobación pegada. No oculta nada: el archivo sigue siendo el mismo. El cifrado es el único de los tres que aporta confidencialidad, y solo es tan fuerte como la clave. Ahí es donde entra una contraseña realmente aleatoria.
Si estabas a punto de pasar un secreto a Base64
No lo hagas. En concreto:
- Los archivos de configuración con contraseñas en Base64 (un patrón habitual en aplicaciones Java y .NET antiguas) contienen contraseñas en texto plano para cualquiera que abra el archivo.
- Las claves de API “ofuscadas” en el JavaScript del front-end se ven en la pestaña de red, estén en Base64 o no.
- La autenticación Basic sobre HTTP sin cifrar envía el usuario y la contraseña codificados en Base64, es decir, en claro. Solo es aceptable dentro de HTTPS, donde el transporte se encarga del cifrado.
Si hay datos que deben guardarse o enviarse sin que nadie más los lea, cífralos con un algoritmo de verdad (AES-256-GCM mediante la biblioteca criptográfica de la plataforma) y después, si tienen que pasar por un canal de texto, codifica el texto cifrado en Base64. Codificar después de cifrar está bien. El error es codificar en lugar de cifrar.
