El = al final de un string Base64 es relleno. Base64 trabaja con grupos de tres bytes, y cuando a la entrada le faltan uno o dos bytes para el último grupo, el codificador completa el grupo de cuatro caracteres con = para que la longitud de la salida siga siendo múltiplo de cuatro. Un = significa que el último grupo tenía dos bytes. Dos significan que tenía uno. El relleno no lleva datos propios, y por eso muchas veces se puede quitar y volver a poner.
¿Por qué hace falta rellenar el último grupo?
Base64 corta la entrada en grupos de 24 bits, tres bytes cada uno, y escribe cada grupo como cuatro caracteres de seis bits. La mayoría de las entradas no se dividen exacto, así que el último grupo queda corto. El codificador completa los bits que faltan con ceros hasta tener un número entero de caracteres de seis bits, y luego agrega = hasta llegar a cuatro caracteres. El RFC 4648 describe justo estos dos casos para el grupo final: ocho bits de entrada se vuelven dos caracteres y ==, dieciséis bits se vuelven tres caracteres y =.
| Entrada | Bytes | Base64 | Relleno |
|---|---|---|---|
M | 1 | TQ== | dos |
Ma | 2 | TWE= | uno |
Man | 3 | TWFu | ninguno |
No hay fila para tres =. Tres bytes faltantes serían un grupo entero que nunca se empezó, así que simplemente no se escribe. Si ves ===, el string lo produjo algo que no es un codificador estándar, o alguien lo editó a mano.
¿Se puede dejar el relleno afuera?
A menudo sí, y varios formatos lo hacen. El relleno es redundante: la longitud del string sin relleno ya dice cuántos bytes tenía el último grupo. El RFC 4648 dice que los codificadores deben incluir el relleno salvo que la especificación que lo usa indique otra cosa, y su sección sobre el alfabeto seguro para URL añade que el = suele codificarse con porcentaje en una URI, así que se puede omitir cuando la longitud de los datos se conoce por otro medio. Por eso las partes base64url de un JSON Web Token no llevan ninguno (qué contiene un JWT muestra dónde están), y por eso la salida URL-safe del codificador y decodificador Base64 de aquí también lo quita.
El costo lo paga quien decodifica. Un decodificador que exige el relleno rechaza un string sin él. base64.b64decode de Python es el ejemplo habitual: lanza un error de «Incorrect padding» con un string cuya longitud no es múltiplo de cuatro. Los decodificadores tolerantes lo restauran en silencio. Si un token decodifica en un lugar y falla en otro, cuenta los caracteres antes de sospechar de cualquier otra cosa.
Cuando un decodificador tiene que restaurarlo, la regla es mecánica: agrega = hasta que la longitud sea múltiplo de cuatro. El decodificador de este sitio lo hace, y además quita antes cualquier espacio en blanco.
¿Qué te dice la longitud antes de decodificar?
Toma el string sin relleno y divide su longitud entre cuatro. El resto dice cómo terminó la entrada.
- Resto 0. La entrada era un número entero de grupos de tres bytes, o el string está rellenado y completo.
- Resto 2. El último grupo tenía un byte. Dos caracteres dan doce bits, y los últimos cuatro son relleno.
- Resto 3. El último grupo tenía dos bytes. Tres caracteres dan dieciocho bits, y los últimos dos son relleno.
- Resto 1. Imposible. Un carácter lleva seis bits, que es menos que un byte. Ningún codificador produce esa longitud, así que el string se cortó o le agregaron algo.
El número de bytes es la longitud por tres, dividida entre cuatro, redondeada hacia abajo. Un string de 22 caracteres una vez quitado el relleno contiene 16 bytes, y 22 deja resto 2, lo cual encaja con un valor de 16 bytes como un UUID o un bloque AES. Una longitud con resto 1 es la prueba más rápida de que un string copiado perdió el final. El decodificador de aquí informa ese caso como truncado en lugar de devolver bytes que parecen plausibles.
Lo que una revisión de longitud no puede detectar
Si un string se corta justo en el límite de un grupo, sigue siendo Base64 válido. El resto es 0, decodifica sin quejas y entrega menos bytes de los que se enviaron. La única protección contra eso es algo externo al string: una longitud declarada, un checksum o una firma. Es el mismo límite que tiene cualquier comparación de hash, y conviene recordarlo cuando un valor decodificado «funciona» pero resulta más corto de lo esperado.
Los bits de relleno son una segunda rareza. En el grupo final deberían ser cero, pero un decodificador puede ignorarlos. Según el algoritmo del WHATWG que usan los navegadores para atob(), YQ e YR decodifican ambos a la letra a, porque los últimos cuatro bits del segundo carácter se descartan, así que dos strings distintos dan un solo valor. Si comparas strings Base64 como texto para decidir si dos valores son iguales, decodifícalos primero.
¿Cómo tratan el relleno que falta los navegadores y las bibliotecas?
No se ponen de acuerdo entre sí, y de ahí vienen la mayoría de los errores de relleno.
atob()del navegador. Acepta un string sin relleno, y también con él. Falla con un resto de longitud de 1, y con cualquier carácter fuera del alfabeto estándar, lo que incluye-y_. Un string base64url hay que convertirlo de vuelta a+y/antes de queatob()lo lea.- Bibliotecas estrictas. Muchas exigen el relleno con el alfabeto estándar, como el ejemplo de Python de arriba.
Buffer.from(s, 'base64')de Node. Acepta ambos alfabetos y no insiste en el relleno.
El comportamiento cambia entre versiones y bibliotecas, así que para cualquier cosa de la que dependas, prueba el decodificador exacto que va a ejecutar tu código, con un string rellenado y uno sin rellenar de cada resto de longitud.
Qué falla cuando el relleno se encuentra con una URL
Un = literal en un query string es también el separador entre una clave y su valor, y los decodificadores de formularios lo tratan así. Un Base64 estándar dentro de una URL puede terminar con el relleno comido o partido, lo que da ese tipo de error intermitente que solo aparece con ciertas entradas, las que tienen una longitud con resto. La solución es usar base64url sin relleno, o codificar el = con porcentaje como %3D. La codificación de URL explicada cubre por qué hace falta ese segundo paso.
Dos strings rellenados pegados uno tras otro tampoco forman un solo Base64. TQ==TQ== tiene relleno en el medio, y la mayoría de los decodificadores lo rechazan o dejan de leer en el primer =. Decodifica cada pieza por separado y une los bytes.
Lo que esta herramienta no hace
El decodificador es tolerante a propósito. Quita los espacios en blanco, restaura el relleno que falta y acepta cualquiera de los dos alfabetos en el mismo string, así que leerá una entrada que una biblioteca estricta rechazaría. No ofrece un modo estricto, así que no puede decirte que tu relleno estaba mal; solo puede decirte que la longitud es imposible. Tampoco avisa de bits de relleno distintos de cero. Trabaja con texto pegado, no con archivos, y corre en la pestaña, así que un token que estás depurando se queda en tu computadora.
Para ver cómo aparece y desaparece el relleno, pega M, Ma y Man en el codificador y decodificador Base64, alterna entre el alfabeto estándar y el URL-safe, y mira el conteo de caracteres. Nada sale de tu navegador.
Si necesitas el panorama más amplio de para qué sirve Base64 y cuánto cuesta, qué es Base64 y cuándo lo necesitas de verdad parte de la proporción de tres bytes a cuatro caracteres que este artículo da por sabida.
Preguntas frecuentes
¿Qué significa el = al final de un string Base64?
Es relleno. Base64 codifica tres bytes como cuatro caracteres, y cuando a la entrada le sobran uno o dos bytes al final, el codificador agrega = hasta que la longitud sea múltiplo de cuatro. Un = significa que el último grupo tenía dos bytes, y dos = significan que tenía uno.
¿Puedo quitar el relleno = de un Base64?
Normalmente sí, si lo que lo lee lo acepta. El relleno se puede recalcular a partir de la longitud del string, por eso formatos como JWT lo omiten. Un decodificador estricto rechazará un string sin él, así que restáuralo agregando = hasta que la longitud sea múltiplo de cuatro antes de decodificar.
¿Por qué mi string Base64 falla con un error de relleno incorrecto?
El decodificador esperaba una longitud múltiplo de cuatro y recibió otra. Las causas habituales son un relleno quitado por una URL o por un formato como base64url, un carácter perdido al copiar, o espacios en blanco. Agrega = hasta que la longitud sea múltiplo de cuatro; si la longitud sin relleno deja resto 1, el string se cortó y no se puede reparar.
¿Cómo sé si un string Base64 fue truncado?
Quita el relleno y divide la longitud entre cuatro. Un resto de 1 es imposible en una codificación real, así que el string perdió caracteres. Cualquier otro resto es válido, de modo que un string cortado justo en el límite de un grupo parece correcto y decodifica a menos bytes de los enviados; solo una longitud conocida, un checksum o una firma pueden detectarlo.
Última actualización 28 de octubre de 2026
