Codificador y Decodificador Base64

Qué hace esta herramienta

Codifica y decodifica Base64 en las dos direcciones, con tres cosas que la mayoría de conversores online no cubren bien:

• Texto en UTF-8 de verdad: acentos, ñ y emojis van y vuelven intactos.
• Variante URL-safe, la que usan los JWT y los identificadores de API.
• Archivo → Data URI, para incrustar una imagen o una fuente directamente en el CSS o el HTML.

Todo se procesa en tu navegador. Nada se sube.

Qué es Base64 (y qué no es)

Base64, definido en la RFC 4648, representa datos binarios usando solo 64 caracteres de texto seguro: A-Z, a-z, 0-9, + y /, más el = como relleno.

Existe por un motivo muy concreto: hay canales que solo aceptan texto. El cuerpo de un correo electrónico, un atributo de HTML, un campo de JSON, una cabecera HTTP. Por ahí no se puede meter un binario tal cual, porque cualquier byte suelto se interpretaría como un carácter de control o rompería el formato. Base64 traduce ese binario a algo que sobrevive al viaje.

Lo que hay que tener claro: no protege nada

Esto merece decirse aparte porque es un malentendido con consecuencias reales:

Base64 no es cifrado. Decodificarlo no requiere ninguna clave, ni contraseña, ni permiso. Es una operación pública que hace cualquier navegador en un clic — de hecho, la de esta misma página.

Ver una cadena de aspecto ilegible dentro de un token, una cookie o un archivo de configuración y suponer que “está protegida” es un error frecuente. Lo único que hace Base64 es cambiar el alfabeto, no ocultar el contenido.

Si lo que necesitas es:

• Confidencialidad → cifrado (AES, por ejemplo).
• Comprobar que algo no ha cambiado → un hash, que puedes calcular en el generador de hash.
• Que solo se pueda leer con permiso → cifrado más control de acceso.

Base64 no es ninguna de las tres.

Cómo funciona, en una línea

Toma la entrada de tres en tres bytes (24 bits) y los reparte en cuatro grupos de seis bits (2⁶ = 64, de ahí el nombre). Cada grupo de seis bits se traduce a uno de los 64 caracteres.

De ahí salen las dos propiedades que más se notan:

Ocupa un 33 % más. Tres bytes se convierten en cuatro caracteres, así que todo crece un tercio. Es el precio de poder viajar como texto.

Los = del final son relleno. Si la entrada no es múltiplo de tres, sobra hueco en el último grupo y se completa con uno o dos = para que la salida sea siempre múltiplo de cuatro. No aportan información; algunos sistemas los omiten y es válido mientras el decodificador lo tolere.

El problema con los acentos y los emojis

Si has intentado codificar texto en español con JavaScript, probablemente te has encontrado esto:

btoa('mañana')
// InvalidCharacterError: The string to be encoded contains characters
// outside of the Latin1 range.

La razón: btoa() solo acepta caracteres de un byte. Es una función de los años noventa, anterior a que Unicode fuera lo normal. Una ñ ocupa dos bytes en UTF-8, un emoji hasta cuatro, y la función no sabe qué hacer con ellos: o lanza el error de arriba o —peor— devuelve algo corrupto en silencio.

La forma correcta es convertir el texto a bytes UTF-8 antes de codificar:

// Codificar
const bytes = new TextEncoder().encode('mañana 🥖');
const b64 = btoa(String.fromCharCode(...bytes));

// Decodificar
const back = new TextDecoder().decode(
  Uint8Array.from(atob(b64), c => c.charCodeAt(0))
);

Esta herramienta hace exactamente eso, así que puedes pegar español, chino o emojis y volverán intactos. Es un buen banco de pruebas cuando sospechas que la corrupción viene de otra capa de tu sistema.

Base64 URL-safe

En una URL, tres de los caracteres de Base64 tienen significado propio:

Meterlos tal cual en una ruta o un parámetro rompe la URL o la altera al pasar por un proxy. La variante URL-safe lo resuelve sustituyendo:

• + → -
• / → _
• y normalmente omitiendo el relleno =

Es la variante que usan los JWT —las tres partes de un token están en Base64 URL-safe— y muchos identificadores de API.

Síntoma práctico: si pegas un token y la decodificación falla o devuelve basura, marca la casilla de URL-safe. Es casi siempre eso. Para leer un JWT completo, con sus campos y su expiración, está el decodificador de JWT.

Data URI: cuándo incrustar y cuándo no

Codificar un archivo como data URI permite meterlo dentro del propio CSS o HTML:

.icono {
  background-image: url("data:image/png;base64,iVBORw0KGgo…");
}

La ventaja es que se ahorra una petición al servidor. La desventaja son tres cosas a la vez:

1. El archivo crece un 33 %.
2. El navegador no puede cachearlo por separado: cada vez que cambie el CSS, se vuelve a descargar la imagen con él.
3. El CSS o el HTML que lo contiene se hincha, y ambos bloquean el renderizado.

La regla práctica: incrustar solo lo diminuto. Un icono de pocos kilobytes o un logotipo SVG sencillo salen rentables; una foto, jamás. A partir de unos pocos kilobytes, una petición extra es más barata que el peso añadido.

Para imágenes de verdad conviene antes reducir el peso con el compresor de imágenes y servirlas como archivo.

Dónde te lo vas a encontrar

• Cabeceras HTTP de autenticación básica: Authorization: Basic dXN1YXJpbzpjbGF2ZQ== es literalmente usuario:clave en Base64. Que sea trivial de decodificar es la razón por la que la autenticación básica exige HTTPS.
• JWT: cabecera y contenido van en Base64 URL-safe, legibles por cualquiera. Solo la firma protege.
• Adjuntos de correo: el estándar MIME los transporta así.
• Claves y certificados en formato PEM: lo que hay entre BEGIN y END es Base64.
• Variables de entorno que necesitan meter un archivo entero en una sola línea.