Relleno en Base64: para qué sirven los signos =

Por qué Base64 necesita relleno

Base64 convierte 3 bytes en 4 caracteres (el algoritmo completo está en cómo funciona Base64). Cuando la longitud de la entrada no es múltiplo de 3, el último bloque queda incompleto:

El = mantiene la longitud de la salida en un múltiplo de 4. Eso facilitaba la vida a los decodificadores de la época de MIME, que podían leer la entrada en grupos fijos de 4 caracteres y saber dónde terminan los datos sin llevar la cuenta de la longitud total.

En sentido estricto, la información es redundante. Un último grupo de 3 caracteres solo puede significar 2 bytes, y uno de 2 caracteres solo puede significar 1 byte, así que a un decodificador que cuenta caracteres no le hace falta ningún =. Por eso es posible el Base64 sin relleno y por eso lo usan muchos formatos.

Hay un caso en el que el relleno sí aporta información real: la concatenación. Si se pegan dos cadenas con relleno, el = del medio marca dónde termina la primera. Aun así, los decodificadores lo manejan mal. Al pasar TQ==TQ== (dos M codificadas) al decodificador por defecto de Python, devolvió b'M\x04\xd0', Buffer de Node devolvió solo M y atob lanzó un error. Decodifica cada trozo por separado.

Cuándo el relleno es opcional

RFC 4648 §3.2 dice que los codificadores DEBEN añadir relleno salvo que la especificación que usa Base64 diga explícitamente lo contrario. Varias lo hacen:

• JWT y JOSE (RFC 7515) usan Base64URL sin relleno. Una cabecera JWT como eyJhbGciOiJIUzI1NiJ9 no tiene = aunque la longitud no sea múltiplo de 4. Consulta Base64 en JWT.
• URLs y nombres de archivo suelen llevar Base64URL sin relleno, porque = tiene un significado en las cadenas de consulta y habría que escaparlo como %3D. La página Base64 vs Base64URL explica la diferencia completa.
• WebAuthn y OAuth PKCE (el code_challenge de RFC 7636) también usan Base64URL sin relleno.

El Base64 estándar del correo, los archivos PEM, las data URI y la mayoría de las APIs JSON lleva relleno. En caso de duda, genera salida con relleno para el Base64 estándar y sin relleno para Base64URL, y haz que tu decodificador acepte ambas.

Decodificadores que exigen relleno

El comportamiento varía más de lo que se suele pensar. Estos son los resultados de decodificar TWE (Ma sin relleno) con el decodificador por defecto de cada biblioteca:

Fíjate en la fila de OpenSSL: no imprimió nada y aun así informó de éxito, así que un script que pase Base64 sin relleno por openssl base64 -d genera sin avisar un archivo vacío. En las mismas pruebas tampoco devolvió nada con una única línea sin salto de línea final; pasar -A resolvió ese caso.

Go es el más estricto en el sentido contrario: RawStdEncoding rechaza una cadena que sí tiene relleno. Si aceptas entradas de varias fuentes, quita los = y usa la codificación raw, o añade el relleno y usa la estándar.

Hay ejemplos para cada lenguaje en las páginas de código, por ejemplo Base64 en Python y Base64 en Go.

Cómo restaurar el relleno que falta

La regla depende solo de la longitud de la cadena tras quitar los espacios en blanco:

Un resto de 1 nunca es válido. Un carácter Base64 lleva 6 bits, que no bastan para un byte, así que ningún relleno lo hace decodificable. Si te encuentras con esto, busca un carácter que falte, uno que sobre o un salto de línea que se haya contado.

El arreglo es una sola expresión en la mayoría de los lenguajes:

import base64
s = "eyJzdWIiOiIxMjM0In0"            # 19 chars, 19 % 4 == 3
padded = s + "=" * (-len(s) % 4)     # adds one "="
print(base64.urlsafe_b64decode(padded))
# b'{"sub":"1234"}'

const s = "eyJzdWIiOiIxMjM0In0";
const padded = s + "=".repeat((4 - (s.length % 4)) % 4);
// "eyJzdWIiOiIxMjM0In0="

El validador Base64 indica la longitud y el estado del relleno de una cadena, y Reparar Base64 añade los = que faltan, quita espacios y comillas y convierte los caracteres URL-safe en un solo paso.

Codificaciones no canónicas

El relleno tiene un pariente más discreto: los bits sobrantes del último carácter de datos. Al codificar Ma, sus 16 bits llenan dos grupos y medio de 6 bits. El tercer carácter lleva los últimos 4 bits de a más 2 bits de relleno, y RFC 4648 §3.5 dice que el codificador debe poner esos bits a cero. Eso da E (000100).

Un decodificador ignora esos bits, así que TWF= (donde F es 000101, con bits sobrantes 01) se decodifica como el mismo Ma. Python, Node, Java y PHP aceptaron TWF= y devolvieron Ma en nuestras pruebas. Del mismo modo, TR== se decodifica como M, igual que TQ==.

Las cadenas como TWF= se llaman no canónicas. Importan en algunos casos:

• Firmas y hashes sobre texto Base64. Dos cadenas distintas se decodifican en los mismos bytes, así que comparar cadenas Base64 para saber si los datos son iguales puede dar una respuesta incorrecta. Compara los bytes decodificados.
• Deduplicación y claves de caché. El mismo problema: normaliza decodificando y volviendo a codificar.
• Analizadores estrictos. RFC 4648 permite a los decodificadores rechazar bits sobrantes distintos de cero. StdEncoding.Strict() de Go y base64 -d de GNU rechazan TWF=.

El relleno de más es una rareza relacionada. TWE== tiene un = de sobra. Python y Buffer de Node lo aceptaron; atob lanzó InvalidCharacterError.

Relleno al codificar por trozos

Si codificas en Base64 un archivo grande por partes, todos los trozos salvo el último deben medir un múltiplo de 3 bytes. Si no, cada trozo recibe su propio relleno y la salida unida es incorrecta. Codificar hello world!! en trozos de 4 bytes dio aGVsbA==byB3bw==cmxkIQ==IQ==; en trozos de 3 bytes dio aGVsbG8gd29ybGQhIQ==, idéntico a codificarlo todo de una vez. Para dividir en líneas al estilo MIME, 57 bytes por línea es el tamaño natural del trozo, ya que 57 bytes se convierten exactamente en 76 caracteres.

Preguntas frecuentes