Codificador/Decodificador Base64

Acerca de Codificador/Decodificador Base64

Base64 reescribe bytes arbitrarios usando solo 64 caracteres: A–Z, a–z, 0–9, + y /. Sirve cuando datos binarios tienen que viajar por un canal pensado para texto: adjuntos de correo, cabeceras de autenticación HTTP Basic, tokens JWT o imágenes incrustadas como data URI.

Esta herramienta convierte primero tu texto a bytes UTF-8 y después escribe esos bytes en Base64. Al decodificar acepta tanto el alfabeto estándar (+ /) como el seguro para URL (- _), y le da igual si hay relleno = al final, espacios o saltos de línea.

Cómo tres bytes se convierten en cuatro caracteres

La RFC 4648 divide la entrada en grupos de 24 bits (tres bytes), corta cada grupo en cuatro trozos de 6 bits y asigna a cada trozo (0–63) un carácter del alfabeto. “Man” son los bytes 4D 61 6E; en bits, 010011 010110 000101 101110, es decir 19, 22, 5 y 46: TWFu.

Si el último grupo queda incompleto se rellena con =. Un byte sobrante da dos caracteres más ==; dos bytes dan tres caracteres más un =. Por eso “M” es TQ== y “Ma” es TWE=. Con relleno, la longitud siempre es múltiplo de cuatro.

La salida mide ceil(n/3) × 4 caracteres. Un archivo de 30.000 bytes se convierte exactamente en 40.000 caracteres (+33 %); uno de 100 bytes, en 136 (+36 %), porque el relleno pesa más en entradas pequeñas. El correo MIME además inserta un salto de línea cada 76 caracteres, así que un adjunto real crece alrededor de un 35 %.

Base64 no es cifrado

No hay clave. Cualquiera con la tabla del alfabeto puede revertirlo, que es exactamente lo que hace el botón de decodificar. dXNlcjpwYXNz parece ilegible, pero es simplemente user:pass.

La autenticación HTTP Basic (RFC 7617) envía “usuario:contraseña” en Base64 dentro de la cabecera Authorization. Sin HTTPS, quien vea la cabecera lee la contraseña. Con los JWT pasa lo mismo: la cabecera y la carga útil están en Base64url, no cifradas. La firma impide modificarlas, pero no oculta nada; pega aquí el segmento central de un token y verás el ID de usuario y la fecha de caducidad. Por eso no se deben poner secretos ni datos personales en un JWT.

A veces se usa Base64 para “esconder” claves de API en código del navegador. Solo detiene miradas casuales: los escáneres de secretos decodifican Base64 de forma rutinaria.

Por qué btoa() falla con acentos y otros alfabetos

btoa() trata cada carácter de la cadena como un solo byte (0–255). Caracteres como 世 (U+4E16) no caben, así que btoa("世界") lanza InvalidCharacterError. El fallo más traicionero es con caracteres que sí caben: btoa("ñ") funciona, pero codifica la ñ como el byte Latin-1 F1 y no como los dos bytes UTF-8 C3 B1. Si el receptor decodifica en UTF-8, obtiene caracteres rotos.

El orden correcto es texto → bytes UTF-8 → Base64. Esta herramienta usa TextEncoder para el primer paso, así que “Hello, 世界” se convierte en SGVsbG8sIOS4lueVjA== (13 bytes UTF-8, no 9 caracteres). Al revés también importa: si un servidor codificó texto en Windows-1252 o ISO-8859-1, aquí se leerá como UTF-8 y aparecerán caracteres �; es lo que suele pasar con correos antiguos en español.

Base64 estándar frente a Base64url

+ y / tienen significado en URL y rutas de archivo. La sección 5 de la RFC 4648 define un alfabeto “URL and Filename safe” que los sustituye por - y _. Los JWT usan ese alfabeto y además eliminan el relleno =.

La opción segura para URL de esta herramienta hace lo mismo: +→-, /→_ y quita los = finales. “<<???>>” es PDw/Pz8+Pg== en estándar y PDw_Pz8-Pg en modo URL. Un error clásico es meter Base64 estándar en una cadena de consulta: un decodificador de formularios convierte + en espacio y el valor deja de decodificarse.

Ejemplos

Cómo se usa

1. Pega el texto que quieres codificar o la cadena Base64 que quieres decodificar.
2. Activa la opción segura para URL si el resultado irá en una URL, un nombre de archivo o un JWT (solo al codificar).
3. Con el botón de intercambio puedes devolver la salida a la entrada y comprobar el viaje de ida y vuelta.

Preguntas frecuentes