Qué es la codificación Base64 y cómo funciona
Base64 es un sistema que representa cualquier dato binario o texto usando solo 64 caracteres ASCII imprimibles (A-Z, a-z, 0-9, + y /), de modo que ese dato sobrevive intacto en sistemas que solo manejan texto de forma segura, como JSON, correo electrónico o una URL.
Lo que Base64 realmente hace
Base64 no es cifrado ni compresión. No hay clave secreta, cualquiera puede decodificarlo con una herramienta gratuita, y el resultado siempre es más grande que el original, nunca más pequeño. Es, literalmente, cambiar de alfabeto: los mismos bytes, escritos con símbolos distintos.
Esto importa porque es el malentendido más común alrededor de Base64. Alguien “codifica” una contraseña o un token en Base64 y lo trata como si estuviera protegido. No lo está. Si un atacante ve la cadena codificada, la revierte en el navegador con una sola línea de JavaScript. Base64 resuelve un problema de compatibilidad (transportar bytes por canales que solo aceptan texto), no un problema de seguridad.
Cómo funciona: codificar “Man” bit a bit
No hay magia detrás del proceso, es una conversión de base: se agrupan los bits de 8 en 8 (bytes) y se reagrupan de 6 en 6 (el tamaño que necesita el alfabeto de 64 símbolos).
Toma el texto “Man”. Cada letra es un byte ASCII:
| Carácter | Valor ASCII | Binario |
|---|---|---|
| M | 77 | 01001101 |
| a | 97 | 01100001 |
| n | 110 | 01101110 |
Concatena esos 24 bits en una sola tira: 010011010110000101101110. Ahora divídela en cuatro grupos de 6 bits en lugar de tres grupos de 8:
| Grupo de 6 bits | Valor decimal | Carácter Base64 |
|---|---|---|
| 010011 | 19 | T |
| 010110 | 22 | W |
| 000101 | 5 | F |
| 101110 | 46 | u |
Cada valor decimal (0-63) apunta a una posición del alfabeto Base64. El resultado de leer los cuatro caracteres en orden es TWFu. Por eso “Man” se convierte en “TWFu”: son los mismos 24 bits, solo que agrupados y leídos con una regla distinta.
Ese cambio de agrupación (8 bits por byte frente a 6 bits por símbolo) es también la razón matemática detrás del famoso “33% más grande”: cada 3 bytes de entrada (24 bits) producen exactamente 4 caracteres de salida, así que la salida siempre pesa un tercio más que la entrada.
Padding: por qué algunas cadenas Base64 terminan en =
El truco de agrupar en bloques de 3 bytes solo funciona limpio cuando la entrada es múltiplo exacto de 3. Cuando no lo es, Base64 rellena el hueco con el carácter =, que no representa datos, solo indica “aquí falta relleno para completar el último grupo de 4”.
| Entrada | Bytes | Salida Base64 | Explicación |
|---|---|---|---|
| M | 1 | TQ== | 1 byte no llena un grupo de 3, quedan 2 caracteres de datos reales más 2 de relleno |
| Ma | 2 | TWE= | 2 bytes producen 3 caracteres de datos reales más 1 de relleno |
| Man | 3 | TWFu | 3 bytes completan el grupo exacto, 4 caracteres, sin relleno |
Si ves una cadena Base64 terminada en ==, sabes que el último bloque de datos originales era de 1 byte. Si termina en un solo =, eran 2 bytes. Si no lleva ningún =, la entrada era múltiplo exacto de 3 bytes.
Dónde te vas a encontrar Base64 de verdad
No es un formato de laboratorio, aparece constantemente en herramientas que ya usas.
Autenticación HTTP Basic. Cuando un cliente envía usuario y contraseña por HTTP Basic Auth, literalmente manda Authorization: Basic <base64(usuario:contraseña)>. Por ejemplo, user:pass1234 se codifica como dXNlcjpwYXNzMTIzNA==. Ojo: esto no cifra nada, solo empaqueta el par usuario:contraseña en un formato que la cabecera HTTP puede transportar sin romperse, por eso HTTP Basic Auth siempre debe ir sobre HTTPS.
JSON embebido en una URL o payload. Un objeto como {"id":42,"active":true} se convierte en eyJpZCI6NDIsImFjdGl2ZSI6dHJ1ZX0=. Es una forma habitual de meter datos estructurados pequeños dentro de un parámetro de URL o de un campo de texto que no admite comillas ni llaves sin escapar.
Data URLs en CSS y HTML. Una imagen pequeña se puede embeber directamente en el CSS o el HTML como data:image/png;base64,..., evitando una petición de red adicional para archivos diminutos como iconos.
Adjuntos de correo (MIME). El estándar MIME usa Base64 para meter archivos binarios (una imagen, un PDF) dentro de un mensaje de correo que, técnicamente, solo transporta texto.
Tokens JWT. Un JWT son tres segmentos Base64url separados por puntos: header.payload.signature. No hace falta una herramienta especializada para leer el payload, cualquier decodificador Base64/Base64url estándar (como el de abajo) te muestra ese segmento en texto plano. Este tool no está pensado para validar firmas JWT, solo para decodificar el texto Base64 que hay dentro de cada segmento.
Dos ejemplos que conviene tener presentes por el tema de Unicode:
“Hello, World!” se codifica como SGVsbG8sIFdvcmxkIQ==.
“café” se codifica como Y2Fmw6k=. Fíjate que son 4 caracteres visibles pero la salida Base64 tiene 8, no los 6 que esperarías contando letras: la é ocupa 2 bytes en UTF-8, y Base64 codifica bytes, no caracteres. Lo mismo pasa con ”🚀”, un único emoji que ocupa 4 bytes en UTF-8 y se codifica como 8J+agA==. Los caracteres fuera del rango ASCII básico (acentos, ñ, kanji, emojis) siempre pesan más bytes de los que su longitud visual sugiere.
Codifica o decodifica tu propio texto
Escribe cualquier texto en el codificador de abajo y verás el resultado en Base64 al instante. Pega una cadena Base64 en el decodificador para recuperar el texto original.
Errores comunes y casos límite
Confundir Base64 con seguridad. Ya se mencionó arriba, pero merece repetirse porque es un error real que ocurre en producción: codificar una contraseña, un token de API o un número de tarjeta en Base64 no lo protege de nada. Cualquiera lo revierte en segundos. Si necesitas proteger un dato, usa cifrado de verdad (por ejemplo AES) con una clave que el atacante no tenga, no una simple representación de caracteres.
Base64 estándar no es seguro para URLs. El alfabeto clásico usa +, / y =, y los tres pueden causar problemas dentro de una URL o un nombre de archivo: + a veces se interpreta como espacio, / se confunde con un separador de ruta, y = puede chocar con el formato de parámetros clave=valor. Por eso existe la variante Base64url, que sustituye + por - y / por _, y normalmente omite el padding. Si ves una cadena parecida a Base64 en una URL o en un JWT que no tiene ningún +, / ni =, probablemente es esta variante, no un error de formato.
Espacios, saltos de línea o padding faltante rompen la decodificación. Algunos decodificadores estrictos rechazan una cadena Base64 si tiene un espacio de más, un salto de línea copiado por accidente, o le falta el = de relleno. Si una decodificación falla y el texto se ve razonable, revisa primero eso antes de asumir que los datos están corruptos.
Codificar dos veces por error. Si tomas una cadena que ya está en Base64 y la vuelves a codificar en Base64, obtienes una cadena válida pero inútil: al decodificarla una sola vez no recuperas el texto original, solo la primera capa de Base64 (que sigue pareciendo texto codificado). Hay que decodificar tantas veces como capas se aplicaron. Si el resultado de decodificar sigue pareciendo Base64, probablemente ese es el caso.
Preguntas frecuentes
¿Base64 es lo mismo que cifrado? No. Base64 es una codificación reversible sin clave secreta, cualquiera puede decodificarla con una herramienta pública. El cifrado, en cambio, necesita una clave para revertirse y está pensado precisamente para ocultar el contenido. Nunca uses Base64 para proteger datos sensibles.
¿Por qué la salida Base64 siempre es más grande que la entrada? Porque el sistema convierte grupos de 3 bytes (24 bits) en 4 caracteres, y cada carácter Base64 solo transporta 6 bits de información útil en vez de los 8 bits que trae un byte normal. El resultado es que la salida pesa aproximadamente un 33% más que los datos originales, no menos.
¿Puedo decodificar un JWT completo con un decodificador Base64 normal? Puedes decodificar cada segmento por separado (header y payload van separados por puntos y son Base64url), y verás el JSON de cada uno en texto plano. Lo que un decodificador Base64 genérico no hace es verificar la firma criptográfica del tercer segmento, eso requiere conocer la clave secreta o pública usada para firmarlo.
¿Por qué “café” no se codifica igual que otras palabras de 4 letras? Porque Base64 codifica bytes, no letras. En UTF-8 la mayoría de letras acentuadas ocupan 2 bytes en vez de 1, así que “café” son en realidad 5 bytes (c-a-f-é de 2 bytes), no 4, y por eso su Base64 tiene 8 caracteres en vez de los 6 que darían 4 bytes de ASCII puro.
¿Qué significan los signos = al final de una cadena Base64?
Son relleno (padding), no datos. Aparecen cuando la longitud de la entrada original no es múltiplo exacto de 3 bytes: un = significa que sobraban 2 bytes en el último grupo, == significa que sobraba 1 byte. Una cadena cuya entrada era múltiplo exacto de 3 no lleva ningún signo =.