Codificador y decodificador Base64

Base64 es una forma de escribir cualquier secuencia de bytes usando solo 64 caracteres imprimibles: letras, dígitos y dos signos. Existe porque hay muchos canales que se diseñaron para transportar texto y no bytes arbitrarios —el correo electrónico, una cabecera HTTP, un campo de un JSON, un atributo de HTML—, y meter ahí un byte cualquiera los rompe. Codificar en Base64 es el peaje que se paga para que unos bytes pasen por un sitio pensado para letras.

Esta herramienta hace las dos direcciones: convierte texto a Base64 y devuelve a texto una cadena Base64. Trabaja con UTF-8 de verdad, así que las eñes, los acentos, el euro y los emojis se codifican bien; admite la variante URL-safe; ignora los saltos de línea al decodificar; y con el botón de intercambiar puedes pasar el resultado a la entrada y comprobar que el viaje de ida y vuelta devuelve exactamente lo que había.

Lo que Base64 no hace, y conviene decirlo pronto: no cifra, no protege y no oculta nada. Es una transformación pública que revierte cualquiera —esta misma página, sin ir más lejos—. Tampoco sirve aquí para archivos: la herramienta va de texto a texto, así que el Base64 de una imagen dará error al decodificarlo porque esos bytes no forman texto.

Base64 toma los bytes de tres en tres. Tres bytes son 24 bits, y esos 24 bits se reparten en cuatro trozos de 6. Con 6 bits hay exactamente 64 combinaciones posibles, y a cada una le corresponde un carácter del alfabeto: A-Z, a-z, 0-9 y dos signos más. Por eso el resultado solo contiene ASCII imprimible y sobrevive a cualquier canal de texto.

Cuando la longitud no es múltiplo de tres, el último grupo queda cojo: se completa con ceros y se añaden uno o dos signos «=» para indicar cuántos bytes eran de relleno. Esa es la única función del «=», y de ahí que la variante URL-safe pueda prescindir de él: la propia longitud de la cadena basta para deducir el relleno al decodificar.

Antes de todo eso hay un paso que se olvida a menudo: convertir el texto en bytes. Un texto no es una secuencia de bytes hasta que eliges una codificación, y aquí se usa UTF-8. La herramienta lo hace con TextEncoder, de modo que la «ñ» entra como dos bytes (C3 B1) y un emoji como cuatro. Al decodificar se recorre el camino inverso con TextDecoder en modo estricto: si los bytes no forman UTF-8 válido, se avisa en lugar de devolver una ristra de símbolos rotos.

Codificar y cifrar se parecen en que las dos cosas producen algo ilegible a simple vista, y ahí termina el parecido. Base64 no tiene clave: la transformación está publicada en un RFC, es reversible y la deshace cualquiera con dos clics. Una contraseña guardada «en Base64» en un fichero de configuración, en una cookie o en una columna de la base de datos está en claro, solo que con un paso de despiste.

El malentendido tiene versiones muy extendidas. La autenticación Basic de HTTP manda usuario y contraseña en Base64 en la cabecera Authorization, y lo que protege esa credencial es el TLS del canal, no la codificación. Los JWT llevan cabecera y contenido en Base64URL, legibles por quien los intercepte; lo que impide falsificarlos es la firma. En ninguno de los dos casos el Base64 aporta un gramo de confidencialidad.

Los 62 primeros caracteres (A-Z, a-z, 0-9) son idénticos en las dos variantes. La diferencia está en los dos últimos y en el relleno, y no es un capricho: «+» y «/» ya significan algo dentro de una URL. En una cadena de consulta el «+» se interpreta como un espacio, y la «/» separa segmentos de ruta, así que un Base64 estándar metido en una URL llega cambiado o directamente roto.

Por eso el RFC 4648 define en su sección 5 una variante con «-» y «_», que además suele escribirse sin relleno porque el «=» también se convierte en «%3D» al pasar por una URL. Es la que usan los JWT, los cursores de paginación de muchas API y cualquier valor que acabe formando parte de una dirección o de un nombre de fichero. Al decodificar no hace falta saber cuál te han dado: los dos alfabetos son inequívocos y esta herramienta acepta los dos.