Codificar en Base64

Base64 no cifra ni comprime: reescribe bytes usando solo 64 caracteres que sobreviven a casi cualquier transporte. Toma tres bytes, los mira como 24 bits y los reparte en cuatro trozos de seis, y cada trozo se convierte en un carácter de la tabla.

De ahí sale su coste: el resultado ocupa un tercio más que el original, siempre. Es el precio de poder atravesar un canal que solo entiende texto, y es la razón por la que un adjunto de correo pesa más que el archivo que hay dentro — el correo sigue siendo un protocolo de texto por dentro.

El alfabeto estándar usa `+` y `/` para los dos últimos caracteres. Ambos tienen significado dentro de una URL: la barra separa segmentos de ruta y el más se lee como espacio en un query string. Un valor en Base64 estándar metido en una dirección llega, por tanto, cambiado.

La variante segura para URL cambia esos dos por `-` y `_`, que no significan nada en ninguna parte de una dirección. Es lo que usan los JWT, y es la razón por la que un token que copias de una cabecera no lleva ni barras ni signos de más. Si el valor va a viajar en una URL, esa es la opción; si no, la estándar es la que espera todo lo demás.

Base64 trabaja de tres bytes en tres. Cuando la entrada no es múltiplo de tres, sobra uno o dos, y el relleno se marca con uno o dos signos igual al final. Por eso un resultado termina en `=`, en `==` o en nada, y por eso su longitud siempre es múltiplo de cuatro.

Ese relleno es opcional en varias especificaciones y obligatorio en otras, lo que provoca un desencuentro recurrente: los JWT lo omiten a propósito, mientras que muchas bibliotecas se niegan a decodificar sin él. Si algo rechaza un valor que parece correcto, el número de caracteres es lo primero que hay que mirar.

Base64 codifica bytes, no caracteres, así que primero hay que decidir cómo se convierte el texto en bytes. Aquí es siempre UTF-8, donde una `á` son dos bytes y una `ñ` también, y un emoji cuatro. La cadena en Base64 es correspondientemente más larga que si el texto fuera solo ASCII.

Ahí está el fallo más habitual al comparar con otra herramienta: si la otra parte usó Latin-1, la `ñ` fue un byte en vez de dos y el resultado no coincide. No es un error de ninguno de los dos codificadores — es que estaban codificando textos distintos, y el desencuentro está una capa más abajo.

La cabecera `Authorization: Basic` es exactamente `usuario:contraseña` en Base64, y nada más. Cualquiera que vea la cabecera puede deshacerla en un segundo, porque no hay clave ninguna: es una codificación, no un cifrado.

Lo que protege esas credenciales es HTTPS y solo HTTPS. Por eso Basic Auth sobre HTTP plano equivale a enviar la contraseña en claro, y por eso una cabecera de esas en una captura de pantalla, en un ticket o en un registro es una credencial expuesta. Que parezca ilegible no cambia nada.

Una imagen en Base64 dentro de un `src` ahorra una petición, y es lo razonable para un icono pequeño o un SVG de pocos kilobytes. A partir de ahí deja de compensar: el archivo crece un tercio, se incrusta en el HTML y por tanto no se cachea por separado, y el navegador tiene que analizarlo antes de pintar nada.

El punto en el que cambia el signo depende de la página, pero la regla de andar por casa aguanta: por debajo de unos pocos kilobytes casi siempre gana la data URI; por encima de unas decenas casi siempre pierde. Una imagen grande incrustada convierte cada visita en una descarga completa del HTML inflado.

Aparece con cierta frecuencia como forma de «esconder» una clave en el código de una aplicación, en un fichero de configuración o en un script. No esconde nada: la vuelta es un botón, y las herramientas que buscan secretos filtrados reconocen las cadenas Base64 precisamente porque es un patrón muy fácil de detectar.

Lo que sí hace es quitarle el aviso a quien mira por encima, y ese es el problema: un secreto en claro se ve y se corrige, uno en Base64 pasa una revisión. Si algo tiene que quedar oculto hace falta cifrado con una clave que viva en otro sitio, o directamente no meterlo ahí.

El correo parte el Base64 en líneas de 76 caracteres porque un estándar de 1996 lo exige, y los certificados en formato PEM usan 64. Ese formato es completamente válido, pero muchos decodificadores modernos se atragantan con los saltos de línea si no los quitan primero.

Esta página genera una sola línea continua, que es lo que espera prácticamente cualquier API actual. Si tienes que pegar el resultado en algo que exige el formato por líneas, el corte lo tendrás que hacer tú — y si estás decodificando algo con saltos, el decodificador de esta web los ignora.

Cualquier texto se codifica en Base64: no hay entrada inválida, y por tanto tampoco hay error posible en este sentido. Eso es cómodo y esconde una trampa, porque una cadena en Base64 puede contener perfectamente basura y seguir teniendo un aspecto impecable.

La comprobación, si hace falta, va antes: si estás codificando JSON, valídalo primero; si estás codificando un identificador, mira que sea el correcto. Un valor mal formado codificado se ve exactamente igual que uno bueno, y el error aparece al otro lado, donde cuesta mucho más encontrarlo.

Lo que se pega en este campo suele ser justo lo que no conviene mover: credenciales, un payload con datos de clientes, el contenido de un fichero de configuración. Como la codificación ocurre en la página, no hay comunicación a nosotros y por tanto tampoco encargo de tratamiento sobre ese contenido.

Se comprueba en el panel de red: mientras usas la herramienta no sale ninguna petición que lleve tu entrada. Lo que sí queda está en la política de privacidad — la visita y las peticiones de publicidad y analítica. El contenido del campo no está entre ellas, y en esta clase de valor eso es lo único que importa.

Decodificar tiene su propia página, y la separación no es por comodidad. Quien codifica está construyendo algo y tiene una decisión que tomar: qué alfabeto. Quien decodifica está leyendo algo que le ha llegado y tiene un problema distinto: qué hacer cuando lo que sale no es texto.

Las dos páginas comparten el mismo motor y explican cosas distintas porque los fallos son distintos. Juntarlas obligaría a cada visitante a leer la mitad que no le sirve, y dejaría fuera precisamente los detalles por los que ha llegado.