Base64 explicado: cómo funcionan la codificación y la decodificación

Qué es realmente Base64

Base64 es una forma de escribir bytes cualesquiera usando solo 64 caracteres seguros. Esa es toda la idea. No es cifrado, ni compresión, ni una suma de control. Resuelve un problema muy concreto: tienes datos binarios y el canal por el que necesitas pasarlos solo admite texto.

Ese canal puede ser el cuerpo de un correo, un campo JSON, una URL, una cabecera HTTP, un archivo YAML o un fichero PEM. Si envías bytes crudos, algo en el camino los estropeará: un byte nulo corta una cadena, un 0x0D se reescribe en una conversión de fin de línea, un byte alto se reinterpreta en otro juego de caracteres. Base64 evita todo eso usando solo letras, dígitos y dos signos de puntuación, y todos sobreviven a ser tratados como texto.

El coste es el tamaño: la salida es alrededor de un tercio más grande que la entrada. Ese es el trato, y casi siempre vale la pena, porque la alternativa son datos que llegan corruptos.

Cómo tres bytes se convierten en cuatro caracteres

Base64 trabaja con grupos de tres bytes. Tres bytes son 24 bits, y 24 se divide limpiamente en cuatro grupos de seis. Cada grupo de 6 bits indexa un alfabeto de 64 caracteres, así que tres bytes de entrada producen cuatro caracteres de salida.

Toma los tres bytes de Man:

M = 77 = 01001101, a = 97 = 01100001, n = 110 = 01101110

Concatena los bits y vuelve a partirlos en seises:

010011 010110 000101 101110 → 19, 22, 5, 46 → T, W, F, u

Así que Man se codifica como TWFu. Cuatro caracteres, sin relleno, porque los tres bytes dividían exacto. Ese «dividían exacto» es justo el detalle del que trata la sección siguiente.

Los 64 caracteres

Los índices 0–25 son A–Z, 26–51 son a–z, 52–61 son 0–9, y 62 y 63 son los dos que causan todos los problemas. En el Base64 estándar son + y /.

El alfabeto, y por qué hay dos

+ y / son perfectamente válidos en el cuerpo de un correo y abiertamente hostiles en una URL. / es un separador de rutas y + significa un espacio en una cadena de consulta, así que un valor Base64 pegado en una URL puede volver con los bytes cambiados y sin ningún error por ninguna parte.

De ahí base64url, una variante que conserva los primeros 62 caracteres y cambia los dos últimos: - por + y _ por /. Es la codificación que usan los JSON Web Token —si alguna vez has leído un JWT a mano, has leído base64url— y todo lo demás que viaja en una URL o en un nombre de archivo.

Por lo demás las dos variantes son idénticas, y eso es precisamente lo que hace peligroso mezclarlas. Una cadena que no contenga ningún +, /, - ni _ es válida en ambas y se decodifica igual. Una que sí los contenga se decodifica a bytes distintos según la variante que suponga el decodificador, normalmente sin lanzar ningún error. Nuestro codificador y decodificador Base64 indica qué alfabeto ha detectado precisamente por esto.

El relleno, y por qué los decodificadores no se ponen de acuerdo

La entrada rara vez es un múltiplo de tres bytes. Un byte sobrante da dos caracteres, dos bytes sobrantes dan tres, y el Base64 estándar rellena el grupo hasta cuatro con signos =:

• 3 bytes → 4 caracteres, sin relleno
• 2 bytes → 3 caracteres + =
• 1 byte → 2 caracteres + ==

El relleno no lleva datos. Existe para que un decodificador que lee un flujo concatenado sepa dónde acaba un valor codificado. Si decodificas una sola cadena aislada, no lo necesitas en absoluto; por eso base64url suele quitarlo, y por eso = resulta incómodo en una URL de todos modos.

El problema práctico

Algunos decodificadores exigen el relleno y rechazan de plano una cadena sin él. Otros aceptan cualquiera de las dos formas. Esta es la causa más común de que un token que funciona en un lenguaje falle en otro con un seco «base64 no válido». La solución casi siempre es devolver el relleno: añade = hasta que la longitud sea múltiplo de cuatro. Un decodificador estricto con el relleno no está roto, y tampoco lo está el codificador que lo omitió: cada uno sigue una mitad distinta de la misma especificación.

Base64 no es cifrado

Esto merece su propia sección porque el error es muy común y muy caro. Base64 no tiene clave. No oculta nada. Revertirlo es una sola llamada de función, disponible en todos los lenguajes y en cualquier página como esta.

El ejemplo canónico es la autenticación HTTP Basic. Una cabecera Authorization: Basic no es más que usuario:contraseña en Base64. Parece opaca, y ahí está justo el peligro: a quien no haya decodificado una le suena a «cifrado», cuando en realidad cualquiera que vea la petición puede leer las credenciales. Por eso Basic solo es aceptable sobre HTTPS: el secreto lo aporta el transporte, la codificación no aporta ninguno.

Lo mismo vale para la carga útil de un JWT, para un bloque Base64 en un archivo de configuración y para una clave de API que alguien «ofuscó» antes de subirla al repositorio. Si lo único que hay entre un atacante y tu secreto es Base64, no hay nada entre un atacante y tu secreto. Nuestra guía para decodificar y depurar JSON Web Tokens profundiza en lo que eso significa para los tokens en particular.

Dónde te encuentras Base64 de verdad

Una vez reconoces la forma, lo ves en todas partes:

• Adjuntos de correo. MIME transporta binario así desde principios de los noventa, cortado a 76 caracteres por línea.
• data: URI. Una imagen pequeña incrustada en CSS o HTML como data:image/png;base64,…, cambiando una petición HTTP por un tercio más de bytes.
• Archivos PEM. Los certificados y las claves entre marcas -----BEGIN… son Base64 del DER subyacente, cortado a 64 caracteres.
• JWT. La cabecera y la carga útil son JSON en base64url; la firma es base64url de bytes crudos.
• Basic auth y algunas credenciales de API. Como arriba, y con la misma advertencia.
• Binario dentro de JSON. JSON no tiene tipo byte, así que los bytes viajan como una cadena Base64.

Por qué algunos Base64 tienen saltos de línea

MIME corta a 76 caracteres y PEM a 64, porque los formatos en los que viven son anteriores a las líneas largas. Esos saltos no forman parte de los datos y un decodificador debe ignorarlos. La mayoría lo hace; unos pocos no, y por eso pegar un cuerpo PEM con saltos en un decodificador estricto a veces falla hasta que quitas los saltos de línea.

El coste en tamaño, y cuándo importa

Cuatro caracteres por cada tres bytes es una expansión de 4/3 —un 33 % aproximado— antes del relleno y los saltos de línea. Para un valor de configuración puntual es irrelevante. Para cualquier cosa en una ruta caliente no lo es.

Una imagen de 10 KB incrustada como data: URI cuesta unos 13,3 KB de HTML y, a diferencia de una imagen real, no se puede cachear por separado ni cargar de forma diferida. Un token enviado en cada llamada de API carga con su sobrecoste en cada petición. Y la compresión no te salva: la salida Base64 se comprime mucho peor que los bytes originales, porque la codificación destruye los patrones a nivel de byte que busca un compresor. Comprime primero, codifica después, nunca al revés.

Codificar texto significa codificar bytes

Base64 codifica bytes. No tiene noción de caracteres, así que «codifica esta cadena en Base64» es siempre una forma abreviada de «convierte esta cadena en bytes y luego codifica esos bytes». El paso intermedio es donde las cosas se rompen, porque necesita una codificación de caracteres y la especificación no elige una por ti.

En la práctica la respuesta es UTF-8, y las API modernas lo usan por defecto. Pero si un lado codifica el texto como UTF-16 o Latin-1 y el otro decodifica como UTF-8, el Base64 es perfectamente válido y el texto que sale es ilegible. La pista es que los caracteres no ASCII sobreviven mal mientras el ASCII puro sobrevive bien, ya que ASCII es un subconjunto de UTF-8.

La prueba de ida y vuelta

Si dudas de si una tubería maneja bien el texto, codifica una cadena con un acento y un carácter no latino, decodifícala otra vez y compara. Todo lo que estropee José o un emoji está perdiendo información en algún punto de la conversión a bytes, no en el Base64 mismo.

Cuando la decodificación sale mal

Cuatro diagnósticos cubren casi todos los casos:

• «Carácter no válido». Se ha colado algo que no está en el alfabeto: casi siempre un espacio perdido, una comilla copiada con la cadena o un prefijo data:image/png;base64, que se quedó delante.
• «Longitud no válida». Tras quitar los espacios, la longitud módulo cuatro es 1, algo que ningún Base64 válido puede producir. Se perdió un carácter en el camino.
• Se decodifica, pero sale ilegible. O los alfabetos no coinciden (base64url decodificado como estándar, o al contrario), o no coincide la codificación de texto, como se ha descrito arriba.
• Se decodifica a bytes que no son texto. Esto no es un error. Mucho Base64 contiene una imagen, una clave o una estructura serializada; un buen decodificador te muestra una vista hexadecimal en lugar de fingir que el resultado es una cadena.

Recorrer esos puntos en orden —caracteres, longitud, alfabeto, codificación— resuelve casi todo. Y cuando un valor simplemente no se decodifica en ninguna parte, la explicación más probable es la más aburrida: estaba truncado. Base64 no lleva comprobación de integridad, así que una cadena que perdió su final se ve exactamente igual que una que nunca lo tuvo.

Herramientas y guías relacionadas:

• Codificador y decodificador Base64: Codifica texto a Base64 o decodifícalo, con salida URL-safe y UTF-8 bien tratado.
• Decodificador JWT: Decodifica un JSON Web Token y lee su cabecera, carga útil, claims y caducidad.
• JWT explicado: cómo decodificar y depurar JSON Web Tokens: Qué contiene un JSON Web Token

Preguntas frecuentes