Los 64 Caracteres Que Componen Base64
Base64 tiene un alfabeto fijo y estándar: exactamente 64 símbolos, más un carácter adicional que se usa únicamente para el relleno. Toda cadena Base64 válida está construida enteramente con ese conjunto. Si aparece un carácter ajeno en medio de tus datos, la cadena no es Base64 válida y un decodificador estricto la rechazará. Entender qué caracteres son legales, cuáles no y por qué aparece el relleno (=) es la forma más rápida de depurar una cadena Base64 que "tiene mala pinta".
El alfabeto está definido en el RFC 4648, el estándar que formaliza Base16, Base32 y Base64. Para la codificación estándar (RFC 4648 §4), los 64 caracteres se corresponden con los valores de índice 0 a 63 así:
- Índices 0–25: las letras mayúsculas de la
Aa laZ - Índices 26–51: las letras minúsculas de la
aa laz - Índices 52–61: los dígitos del
0al9 - Índice 62: el signo más
+ - Índice 63: la barra
/
Ese es todo el alfabeto: 26 + 26 + 10 + 2 = 64. Los dos símbolos no alfanuméricos, + y /, son los que sorprenden — son caracteres Base64 completamente normales, no corrupción. El carácter de relleno = es aparte y no forma parte del alfabeto de 64 valores; aparece solo al final de la cadena, nunca en medio.
Qué Caracteres NO Son Base64 Válidos
Esta es la pregunta que hay detrás de "qué caracteres no son Base64" y "caracteres Base64 ilegales". La respuesta es sencilla: cualquier cosa fuera del conjunto A–Z, a–z, 0–9, + y / (con = permitido solo como relleno final). Es decir, todos estos son inválidos dentro de una carga Base64:
- Los espacios y tabuladores — un espacio colado es el motivo más común de que falle una decodificación.
- Los saltos de línea (
\n,\r) — legales solo en la variante MIME, que parte las líneas cada 76 caracteres; un decodificador estricto en modo "sin espacios en blanco" los rechaza. - El signo de porcentaje (
%), que suele indicar que la cadena venía codificada en URL y hay que decodificarla antes. - Puntuación como
.,,,:,;,@,#,*, comillas y corchetes. - Los sustitutos URL-safe
-y_— legales en el alfabeto URL-safe, pero no en el estándar, y mezclar ambos rompe la decodificación. - Cualquier carácter no ASCII o acentuado (
é,ñ, emojis, "comillas tipográficas" pegadas desde un procesador de texto).
Esto explica directamente por qué un bloque Base64 puede parecer ilegible o no decodificarse. Una cadena Base64 válida es uniforme: nada más que los 64 caracteres del alfabeto y, como mucho, uno o dos = finales. Cuando ves algo que no decodifica, casi siempre contiene alguno de los intrusos anteriores — un salto de línea oculto copiado de una terminal, un espacio inicial, un % de la codificación URL, o comillas curvas de un PDF. Los datos en sí no son "ilegibles"; están contaminados por caracteres que no están en el alfabeto. Elimina los caracteres ajenos (o decodifica primero la capa exterior) y el bloque vuelve a ser válido.
Cómo la Codificación Produce Esos Caracteres
Para entender el alfabeto hay que ver de dónde salen los valores de índice. Como resume el glosario de Base64 de MDN, Base64 trabaja de 3 bytes en 3 bytes. Tres bytes son 24 bits, y 24 se divide de forma exacta en cuatro grupos de 6 bits. Cada grupo de 6 bits es un número de 0 a 63 (porque 26 = 64), y cada uno de esos números selecciona un carácter del alfabeto anterior. Así, cada 3 bytes de entrada se convierten en exactamente 4 caracteres de salida — esa proporción de 4 por 3 es también la razón de que la salida Base64 sea alrededor de un 33% mayor que la entrada.
El motivo de que el alfabeto tenga exactamente 64 símbolos es esa frontera de 6 bits. Seis bits pueden expresar 64 valores distintos y no más, así que la codificación necesita precisamente 64 caracteres imprimibles para tener una correspondencia uno a uno. Menos no cubriría todos los valores; más desperdiciaría el alineamiento limpio de bits.
Un Ejemplo Resuelto: "Man" Se Convierte En "TWFu"
Toma los tres caracteres ASCII Man. Sus valores de byte son 77, 97 y 110, que en binario son:
M= 77 =01001101a= 97 =01100001n= 110 =01101110
Concatenados, es la cadena de 24 bits 010011010110000101101110. Partida en cuatro grupos de 6 bits: 010011, 010110, 000101, 101110 — que son los valores de índice 19, 22, 5 y 46. Búscalos en el alfabeto: 19 → T, 22 → W, 5 → F, 46 → u. El resultado es TWFu. Como la entrada eran exactamente tres bytes, la salida son cuatro caracteres limpios sin relleno.
Por Qué Existe el Relleno: El Carácter "="
Los datos reales rara vez son un múltiplo perfecto de tres bytes. Cuando el último grupo tiene solo uno o dos bytes en lugar de tres, no hay bits suficientes para llenar cuatro caracteres de salida — así que Base64 rellena la salida con = para mantener la longitud múltiplo de cuatro. La regla es precisa:
- Longitud de entrada ≡ 0 (mod 3): sin relleno. Cuatro caracteres reales, p. ej.
TWFu. - Longitud de entrada ≡ 2 (mod 3) (falta un byte): un
=. Dos bytes sobrantes = 16 bits = tres grupos de 6 bits (con dos bits cero añadidos), o sea tres caracteres reales + un=. - Longitud de entrada ≡ 1 (mod 3) (faltan dos bytes): dos
==. Un byte sobrante = 8 bits = dos grupos de 6 bits (con cuatro bits cero añadidos), o sea dos caracteres reales +==.
Ejemplo: codifica Ma (solo dos bytes: 77, 97). Los 16 bits 0100110101100001 se convierten en tres grupos de 6 bits 010011, 010110, 0001+00 de relleno = 19, 22, 4 → T, W, E, y luego un = para completar el cuarteto. El resultado es TWE=. Codifica un solo byte M (77) y obtienes TQ== — dos caracteres reales y dos signos de relleno.
El = le dice al decodificador cuántos bytes representa realmente el último grupo, para que pueda descartar los bits cero sobrantes. Algunos sistemas (en especial el Base64 URL-safe de los JWT) eliminan el relleno por completo porque la longitud es recuperable, pero en Base64 estándar el relleno hace que la cadena se describa a sí misma y que su longitud sea siempre divisible por cuatro. Si alguna vez ves una cadena Base64 cuya longitud no es múltiplo de cuatro y no tiene relleno, es una señal fuerte de que fue truncada o le quitaron el relleno.
Por Qué una Cadena Base64 Puede Empezar Por "/"
Mucha gente se pregunta si es normal que una cadena Base64 empiece por una barra (/) — o por +. Es completamente normal. La barra es el índice 63, un miembro de pleno derecho del alfabeto estándar, y los primeros seis bits de tus datos tienen tanta libertad de ser 111111 (63) como cualquier otro valor. Cualquier secuencia de bytes cuyos seis bits iniciales sean todo unos produce una / al principio. No hay nada especial, roto ni sospechoso en ello.
El motivo de que dé mala espina es que una / inicial parece una ruta de archivo, y un + inicial parece de una operación aritmética — pero dentro de una cadena Base64 son caracteres corrientes. La única situación en la que una / o un + inicial da problemas es cuando la cadena se mete en una URL sin codificarla en formato URL-safe: ahí la / se lee como separador de rutas y el + como un espacio. Ese es exactamente el problema que resuelve la variante URL-safe, no una señal de que tu codificación esté mal. Si tu Base64 vive dentro de una URL, usa el alfabeto URL-safe que se describe a continuación; en cualquier otro sitio, una / inicial es lo esperado. Puedes comprobar todo esto con nuestro codificador Base64 en el navegador.
El Alfabeto URL-safe: "-" y "_"
El RFC 4648 §5 define un segundo alfabeto precisamente para el problema de la / y el +. Es idéntico al estándar salvo que el índice 62 pasa a ser - (guion) en vez de +, y el índice 63 pasa a ser _ (guion bajo) en vez de /. Esos dos sustitutos se pueden meter directamente en URLs y nombres de archivo sin codificación por porcentaje, por lo que los JSON Web Tokens, muchas APIs y las claves de caché lo usan. En la forma URL-safe el relleno también suele omitirse.
Lo crucial es que los dos alfabetos no son intercambiables dentro de una misma cadena: un decodificador configurado para Base64 estándar rechazará - y _, y un decodificador URL-safe rechazará + y /. Si estás depurando una cadena que contiene guiones o guiones bajos, casi con seguridad estás viendo Base64 URL-safe. Cubrimos las diferencias y las reglas de conversión en detalle en Base64 URL-safe frente al estándar, y la mecánica general en Entendiendo la codificación Base64.
"Base44" frente a Base64: Aclarando la Confusión
Una búsqueda recurrente es la "diferencia entre Base64 y Base44". La respuesta corta: Base64 es la codificación estándar de binario a texto, y "Base44" no es un estándar reconocido para ese fin. No existe un equivalente al RFC 4648 que defina un esquema Base44 de propósito general de binario a texto, así que si te han pedido producir o consumir datos "Base44", conviene confirmar qué se quería decir en realidad.
Normalmente pasa una de estas cosas. El término puede ser una errata de Base64. Puede referirse al conjunto de caracteres personalizado de una aplicación concreta (algunos sistemas definen sus propios alfabetos reducidos para IDs cortos o códigos legibles, con nombres improvisados), en cuyo caso solo su documentación lo define. O puede confundirse con los conocidos parientes del mismo RFC — Base32 y Base16 — que sí están estandarizados. Para el intercambio de datos interoperable, tira de Base64 (o de su variante URL-safe); es la codificación en la que coinciden bibliotecas, navegadores y protocolos. No hacemos afirmaciones sobre ninguna implementación concreta de "Base44", porque no hay un único estándar que la defina.
Una Lista Rápida de Depuración
Cuando una cadena Base64 no decodifica, recorre las reglas del alfabeto en orden:
- Busca caracteres ajenos. Cualquier cosa fuera de
A–Z a–z 0–9 + /(más=final) es la culpable — normalmente espacios en blanco, un salto de línea o un%. - Comprueba la longitud. El Base64 estándar es siempre múltiplo de cuatro una vez incluido el relleno. Una longitud que se desvía en uno, dos o tres sugiere relleno eliminado o truncamiento.
- Fíjate en
-o_. Si aparecen, es Base64 URL-safe; decodifícalo con un decodificador URL-safe, no con el estándar. - Una
/o un+inicial no pasa nada — salvo que la cadena esté sin escapar dentro de una URL, en cuyo caso necesitaba el alfabeto URL-safe. - Decodifica antes las capas exteriores. Si ves
%2Fo%3D, la cadena venía codificada en URL; decodifica el porcentaje antes de tratarla como Base64.
Una vez que puedes mirar una cadena y saber al instante si cada carácter pertenece al alfabeto, Base64 deja de ser un misterio. Los bloques "ilegibles" se resuelven en datos válidos o claramente contaminados, y los caracteres =, + y / se leen como lo que son. Prueba cualquier cadena en nuestro codificador Base64 gratuito y solo en el navegador — no se sube nada, y marcará los caracteres fuera del alfabeto.