Cómo funciona Base64

Base64 convierte datos binarios en texto para que puedan viajar por canales que solo manejan caracteres. RFC 4648 define el mecanismo: cada 3 bytes — 24 bits — se convierten en 4 caracteres de un alfabeto de 64 símbolos, con = de relleno cuando los bytes no se reparten en grupos exactos. Aumenta el tamaño de los datos en torno a un tercio y es una codificación, no un cifrado.

Solo local

Los sistemas de correo de los años ochenta movían texto de 7 bits y nada más; las cabeceras HTTP, los campos JSON, las URLs y los archivos de registro son, en la práctica, territorio de solo texto. El binario puro — una imagen, una firma, una clave criptográfica — se corrompe en cuanto un canal así se topa con él. Base64 es el puente estándar: una forma totalmente reversible de escribir bytes arbitrarios usando nada más que 64 caracteres imprimibles seguros.

Llevas todo el día leyendo Base64 sin darte cuenta: cada JWT son tres segmentos Base64url, cada URI data: incrustada en CSS, cada adjunto de correo MIME. El esquema está especificado en RFC 4648 — que unificó en un solo documento las definiciones anteriores de Base-64 — y es lo bastante pequeño para calcularlo a mano. Esta guía hace exactamente eso, un grupo de 24 bits cada vez.

Tres cosas confunden a todo el mundo al principio: por qué 3 bytes se convierten en 4 caracteres, para qué sirven los signos = y por qué hay dos alfabetos. Cada una tiene su propia sección más abajo, junto con los límites honestos — la penalización de tamaño, los desacuerdos sobre los espacios en blanco entre descodificadores y el error persistente de tratar una codificación reversible como si fuera seguridad.

Aquí leer supera a describir — pega cualquier cadena en el descodificador Base64 y observa los bytes que esconde; descodifica localmente, así que los tokens y las claves se quedan en tu pestaña.

El consumidor de Base64 más famoso es el formato de tokens; la la guía de la estructura de JWT muestra cómo los tres segmentos de un JWT viajan sobre el alfabeto URL-safe definido más abajo.

El mecanismo: entran 3 bytes, salen 4 caracteres

Toma cualquier dato binario y córtalo en grupos de 3 bytes — 24 bits. Divide cada grupo en cuatro trozos de 6 bits. Cada trozo es un número del 0 al 63, y el alfabeto de RFC 4648 asigna esos números a caracteres: A–Z para el 0–25, a–z para el 26–51, 0–9 para el 52–61, y luego + y / para el 62 y el 63. Seis bits es el punto ideal, porque 2⁶ = 64 es justo el tamaño de un alfabeto que cualquier canal de solo caracteres puede transportar sin quejarse.

El ejemplo clásico resuelto es el propio vector de prueba del RFC, la palabra Man — tres bytes, sin necesidad de relleno:

Byte a byte

M   0x4D   01001101
a   0x61   01100001
n   0x6E   01101110

joined:    010011 010110 000101 101110
indexes:      19     22      5      46

Carácter a carácter

19→T   22→W   5→F   46→u

"Man"  →  TWFu
"Ma"   →  TWE=
"M"    →  TQ==

El relleno: qué significan los signos =

Los trozos de 6 bits solo se recomponen en bytes en grupos completos de cuatro. Cuando la longitud de la entrada no es múltiplo de 3, el último grupo se queda corto: 2 bytes restantes producen tres caracteres más un signo =, y 1 byte restante produce dos caracteres más ==. El relleno restaura la longitud para que un descodificador pueda calcular el número exacto de bytes sin adivinar — y = es el único carácter fuera del alfabeto de 64 símbolos que puede aparecer en la salida.

El relleno es metadatos de longitud, no seguridad ni compresión. RFC 4648 permite variantes sin relleno cuando ambas partes están de acuerdo — el Base64url de los JWT prescinde del = por completo, porque los puntos delimitan los segmentos y la longitud de cada segmento le dice al descodificador todo lo que necesita.

Bytes de entrada	Caracteres de salida	Relleno	Ejemplo
3 (cualquier múltiplo de 3)	4 por cada 3 bytes	ninguno	"Man" → TWFu
2	3	un =	"Ma" → TWE=
1	2	dos ==	"M" → TQ==
12	16	ninguno	"Hello, world" → SGVsbG8sIHdvcmxk

Los dos alfabetos: estándar y URL-safe

El alfabeto estándar usa + y / — inofensivos en el correo, hostiles en las URLs, donde + se descodifica como un espacio y / como separador de rutas. Por eso RFC 4648 §5 define Base64url, que sustituye + por - y / por _: caracteres que no necesitan codificación porcentual dentro de las URLs ni comillas dentro de nombres de archivo o cookies. Fuera de ahí, los dos dialectos son idénticos — mismos trozos de 6 bits, mismas reglas de relleno.

Ahí está la trampa práctica: los dialectos solo se diferencian en dos caracteres, así que un token pegado con el alfabeto equivocado falla en el segundo carácter — o peor, se descodifica en bytes distintos si resulta contener + o /. Los descodificadores bien comportados aceptan cualquiera de las dos formas y te dicen cuál han visto; los estrictos rechazan de plano los alfabetos mezclados antes que adivinar.

Valores	Estándar	URL-safe
0–25	A–Z	A–Z
26–51	a–z	a–z
52–61	0–9	0–9
62	+	-
63	/	_

Los mismos bytes, dos dialectos

bytes:    0xFB 0xEF 0xBE

standard:  ++++
url-safe:  ----

Dónde duelen los dialectos

en una query de URL, ++++ llega como cuatro espacios
(regla del más como espacio) — ---- llega intacto.
Por eso los tokens usan el alfabeto seguro para URL.

Tamaño: el impuesto del tercio y su letra pequeña

Cuatro caracteres transportan tres bytes, así que la salida codificada es siempre 4/3 de la entrada — un aumento de en torno al 33% — antes de cualquier sobrecoste de transporte. Para anclarlo con números: 100 bytes se codifican en 136 caracteres, 17 bytes en 24, y la proporción nunca se mueve, porque es aritmética y no un ajuste fino. El relleno, los saltos de línea y el ajuste de línea añaden más: MIME limita las líneas Base64 a 76 caracteres y exige saltos CRLF entre ellas, lo que suma un pequeño extra en cargas grandes. Una URI data: incrusta esa forma ya inflada dentro de CSS o HTML, y por eso las imágenes incrustadas pesan aproximadamente un tercio más que los archivos binarios que sustituyen.

Nada reversible encoge los datos, y Base64 no es la excepción — es un cambio de escritura, no compresión. Si el tamaño importa, comprime primero y codifica los bytes comprimidos; nunca al revés.

Espacios en blanco, saltos de línea y desacuerdos entre descodificadores

RFC 4648 es estricto: los descodificadores deben rechazar los caracteres fuera del alfabeto, y el propio documento no dice nada sobre exigir saltos de línea. El Base64 de MIME (RFC 2045) espera justo lo contrario — CRLF cada 76 caracteres. Las implementaciones reales se reparten entre los dos extremos: muchas eliminan los espacios en blanco en silencio, algunas los exigen, otras rechazan cualquier salto de línea. Esa es la razón clásica por la que una cadena que «codifica bien» en una herramienta no se descodifica en otra.

La regla honesta de interoperabilidad: produce Base64 estándar, con relleno y sin partir en líneas, salvo que una especificación diga otra cosa, y construye descodificadores que toleren los espacios en blanco que otras herramientas añaden — sin dejar de rechazar cualquier carácter que no forme parte de un alfabeto reconocido, porque de esa permisividad nace la corrupción silenciosa de bytes.

Lo que Base64 no es

Base64 no tiene clave, ni rondas de mezcla, ni secreto: cualquiera puede invertirlo, y los descodificadores vienen de serie en la biblioteca estándar de todos los lenguajes. Tratar una carga codificada como datos protegidos es un reporte de vulnerabilidad recurrente. Las pistas son públicas: SGVsbG8= deletrea Hello, JVBERi0x abre un PDF, /9j/ empieza un JPEG y eyJ empieza casi cualquier JSON Web Token — esos primeros caracteres son simplemente el Base64 de %PDF-, de los magic bytes de JPEG y de una llave de apertura JSON.

Usa Base64 para lo que es: una forma de escribir bytes que sobrevive a cualquier contenedor. Pon la confidencialidad en cifrado de verdad — TLS en tránsito, un cifrador adecuado para los datos en reposo — y deja Base64 como el último paso que hace imprimible el resultado, nada más.

Aperturas delatoras

SGVsbG8sIHdvcmxk
JVBERi0xLjQ=
/9j/
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Qué revelan al descodificar

Hello, world
%PDF-1.4
(bytes FF D8 FF: el número mágico de un JPEG)
{"alg":"HS256","typ":"JWT"}

Preguntas frecuentes

¿Es seguro pegar tokens y claves en un descodificador Base64?

En este sitio, sí: el descodificador se ejecuta en tu navegador y nunca transmite lo que escribes — no hay ningún endpoint de subida del que se pueda filtrar nada. El panel Network no muestra peticiones mientras descodificas, y la Content-Security-Policy del sitio bloquea las conexiones salientes. Importa porque los tokens en Base64 son credenciales vivas, y muchos descodificadores web al azar son mucho menos cuidadosos con lo que ocurre con ellos.

¿Es Base64 un cifrado?

No — es una codificación sin clave y sin ninguna propiedad de confidencialidad. Cualquier biblioteca, y cualquier persona atenta, puede invertirla al instante; una contraseña codificada es una contraseña visible. El cifrado transforma los datos para que sean ilegibles sin clave, mientras que Base64 solo reescribe los bytes para que los canales de solo texto puedan transportarlos. Las dos cosas resuelven problemas distintos y a menudo aparecen juntas.

¿Por qué la salida de Base64 termina con signos =?

El = es relleno que restaura la longitud. La salida viene en grupos de 4 caracteres, y cuando la entrada no era múltiplo de 3 bytes, el último grupo se completa — un = por dos bytes sobrantes, dos por uno, nunca tres, porque un grupo completo no necesita ninguno. Los signos no llevan datos; le dicen al descodificador el número exacto de bytes.

¿En qué se diferencian Base64 y Base64url?

Dos caracteres. Base64url, definido en RFC 4648 §5, sustituye + por - y / por _ para que la salida sea segura en URLs, nombres de archivo y cookies sin necesidad de escapar. Todo lo demás — la agrupación en 6 bits, las letras y los dígitos, las reglas de relleno — es idéntico, y formatos como los JWT usan la variante URL-safe sin relleno.

¿Por qué la salida de Base64 es más grande que su entrada?

Cada carácter de salida transporta 6 bits, mientras que un byte transporta 8, así que 3 bytes — 24 bits — requieren 4 caracteres: un 4/3 fijo, o en torno al 33% de sobrecoste, antes del relleno y los saltos de línea. Es el precio de mantenerse imprimible; ninguna codificación reversible lo evita, y por eso el transporte binario puro gana allí donde el canal admite bytes de verdad.

¿Puedo descodificar Base64 a mano?

Sí — el diseño lo invita. Escribe los bytes de la entrada en binario, reagrupa cada bloque de 24 bits en cuatro trozos de 6 bits y lee cada trozo en la tabla del alfabeto: A=0 hasta Z=25, a=26 hasta z=51, 0=52 hasta 9=61, y después + y /. El ejemplo del propio RFC sale en papel: Man es 010011 010110 000101 101110, que se lee T, W, F, u — TWFu.

¿Dónde puedo leer las normas citadas aquí?

RFC 4648 — Las codificaciones de datos Base16, Base32 y Base64
RFC 2045 — MIME, primera parte: formato de los cuerpos de mensaje de Internet

Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas