O = no fim de uma string Base64 é preenchimento. O Base64 trabalha com grupos de três bytes, e quando faltam um ou dois bytes para fechar o último grupo, o codificador completa o grupo de quatro caracteres com = para que o tamanho da saída continue sendo múltiplo de quatro. Um = significa que o último grupo tinha dois bytes. Dois significam que tinha um. O preenchimento não carrega dados próprios, e por isso muitas vezes dá para tirá-lo e recolocá-lo.
Por que o último grupo precisa ser preenchido?
O Base64 corta a entrada em grupos de 24 bits, três bytes cada, e escreve cada grupo como quatro caracteres de seis bits. A maioria das entradas não se divide exatamente, então o último grupo fica curto. O codificador completa os bits que faltam com zeros até ter um número inteiro de caracteres de seis bits, e depois adiciona = até chegar a quatro caracteres. A RFC 4648 descreve exatamente esses dois casos para o grupo final: oito bits de entrada viram dois caracteres e ==, dezesseis bits viram três caracteres e =.
| Entrada | Bytes | Base64 | Preenchimento |
|---|---|---|---|
M | 1 | TQ== | dois |
Ma | 2 | TWE= | um |
Man | 3 | TWFu | nenhum |
Não existe linha para três =. Três bytes faltando seriam um grupo inteiro que nunca foi iniciado, então ele simplesmente não é escrito. Se você vir ===, a string foi produzida por algo que não é um codificador padrão, ou foi editada à mão.
Dá para deixar o preenchimento de fora?
Muitas vezes sim, e vários formatos fazem isso. O preenchimento é redundante: o tamanho da string sem ele já diz quantos bytes o último grupo tinha. A RFC 4648 diz que os codificadores devem incluir o preenchimento, a menos que a especificação que o usa diga outra coisa, e a seção sobre o alfabeto seguro para URL acrescenta que o = costuma ser codificado com porcentagem em uma URI, então pode ser omitido quando o tamanho dos dados é conhecido por outro meio. É por isso que as partes base64url de um JSON Web Token não têm nenhum (o que há dentro de um JWT mostra onde elas ficam), e é por isso que a saída URL-safe do codificador e decodificador Base64 daqui também o descarta.
O custo recai sobre quem decodifica. Um decodificador que exige o preenchimento rejeita uma string sem ele. O base64.b64decode do Python é o exemplo de sempre: ele lança um erro de «Incorrect padding» com uma string cujo tamanho não é múltiplo de quatro. Os decodificadores tolerantes restauram o preenchimento em silêncio. Se um token decodifica em um lugar e falha em outro, conte os caracteres antes de suspeitar de qualquer outra coisa.
Quando um decodificador precisa restaurá-lo, a regra é mecânica: adicione = até o tamanho ser múltiplo de quatro. O decodificador deste site faz isso, e antes remove qualquer espaço em branco.
O que o tamanho diz antes de você decodificar?
Pegue a string sem o preenchimento e divida o tamanho dela por quatro. O resto diz como a entrada terminou.
- Resto 0. A entrada era um número inteiro de grupos de três bytes, ou a string está preenchida e completa.
- Resto 2. O último grupo tinha um byte. Dois caracteres dão doze bits, e os últimos quatro são enchimento.
- Resto 3. O último grupo tinha dois bytes. Três caracteres dão dezoito bits, e os últimos dois são enchimento.
- Resto 1. Impossível. Um caractere carrega seis bits, que é menos que um byte. Nenhum codificador produz esse tamanho, então a string foi cortada ou alguém acrescentou algo a ela.
O número de bytes é o tamanho vezes três, dividido por quatro, arredondado para baixo. Uma string de 22 caracteres depois de tirado o preenchimento contém 16 bytes, e 22 deixa resto 2, o que combina com um valor de 16 bytes como um UUID ou um bloco AES. Um tamanho com resto 1 é o teste mais rápido de que uma string copiada perdeu o final. O decodificador daqui informa esse caso como truncado, em vez de devolver bytes com aparência plausível.
O que uma checagem de tamanho não consegue pegar
Se uma string é cortada exatamente no limite de um grupo, ela continua sendo Base64 válido. O resto é 0, ela decodifica sem reclamar e entrega menos bytes do que foram enviados. A única proteção contra isso é algo de fora da string: um tamanho declarado, um checksum ou uma assinatura. É o mesmo limite de qualquer comparação de hash, e vale lembrar quando um valor decodificado «funciona» mas acaba sendo mais curto do que o esperado.
Os bits de enchimento são uma segunda esquisitice. No grupo final eles deveriam ser zero, mas um decodificador pode ignorá-los. Pelo algoritmo do WHATWG que os navegadores usam no atob(), YQ e YR decodificam ambos para a letra a, porque os últimos quatro bits do segundo caractere são descartados, então duas strings diferentes dão um só valor. Se você compara strings Base64 como texto para decidir se dois valores são iguais, decodifique-as primeiro.
Como navegadores e bibliotecas tratam o preenchimento que falta?
Eles discordam entre si, e é daí que vem a maioria dos bugs de preenchimento.
atob()do navegador. Aceita uma string sem preenchimento, e também com ele. Falha com um resto de tamanho 1, e com qualquer caractere fora do alfabeto padrão, o que inclui-e_. Uma string base64url precisa ser convertida de volta para+e/antes de oatob()conseguir lê-la.- Bibliotecas estritas. Muitas exigem o preenchimento no alfabeto padrão, como no exemplo do Python acima.
Buffer.from(s, 'base64')do Node. Aceita os dois alfabetos e não insiste no preenchimento.
O comportamento muda entre versões e bibliotecas, então, para qualquer coisa de que você dependa, teste o decodificador exato que o seu código vai rodar, com uma string preenchida e outra sem preenchimento para cada resto de tamanho.
O que dá errado quando o preenchimento encontra uma URL
Um = literal em uma query string é também o separador entre uma chave e o seu valor, e os decodificadores de formulário o tratam assim. Um Base64 padrão dentro de uma URL pode acabar com o preenchimento engolido ou partido, o que gera aquele tipo de bug intermitente que só aparece com certas entradas, as de tamanho com resto. A correção é usar base64url sem preenchimento, ou codificar o = com porcentagem como %3D. A codificação de URL explicada cobre por que esse segundo passo é necessário.
Duas strings preenchidas coladas uma na outra também não formam um Base64 só. TQ==TQ== tem preenchimento no meio, e a maioria dos decodificadores o rejeita ou para de ler no primeiro =. Decodifique cada pedaço separadamente e junte os bytes.
O que esta ferramenta não faz
O decodificador é tolerante de propósito. Ele remove espaços em branco, restaura o preenchimento que falta e aceita qualquer um dos dois alfabetos na mesma string, então vai ler uma entrada que uma biblioteca estrita recusaria. Ele não oferece um modo estrito, então não consegue dizer que o seu preenchimento estava errado; só consegue dizer que o tamanho é impossível. Também não avisa sobre bits de enchimento diferentes de zero. Ele trabalha com texto colado, não com arquivos, e roda na aba, então um token que você está depurando fica no seu computador.
Para ver o preenchimento aparecer e sumir, cole M, Ma e Man no codificador e decodificador Base64, alterne entre o alfabeto padrão e o URL-safe, e olhe a contagem de caracteres. Nada sai do seu navegador.
Se você precisa do panorama mais amplo do que o Base64 faz e do que ele custa, o que é Base64 e quando você realmente precisa dele parte da proporção de três bytes para quatro caracteres que este artigo considera sabida.
Perguntas frequentes
O que significa o = no fim de uma string Base64?
É preenchimento. O Base64 codifica três bytes como quatro caracteres, e quando sobram um ou dois bytes no fim da entrada, o codificador adiciona = até o tamanho ser múltiplo de quatro. Um = significa que o último grupo tinha dois bytes, e dois = significam que tinha um.
Posso remover o preenchimento = de um Base64?
Normalmente sim, se quem lê aceitar. O preenchimento pode ser recalculado a partir do tamanho da string, por isso formatos como o JWT o omitem. Um decodificador estrito vai rejeitar uma string sem ele, então restaure-o adicionando = até o tamanho ser múltiplo de quatro antes de decodificar.
Por que minha string Base64 falha com um erro de preenchimento incorreto?
O decodificador esperava um tamanho múltiplo de quatro e recebeu outro. As causas comuns são um preenchimento removido por uma URL ou por um formato como o base64url, um caractere perdido ao copiar, ou espaços em branco. Adicione = até o tamanho ser múltiplo de quatro; se o tamanho sem preenchimento deixa resto 1, a string foi cortada e não tem conserto.
Como saber se uma string Base64 foi truncada?
Tire o preenchimento e divida o tamanho por quatro. Um resto de 1 é impossível em uma codificação real, então a string perdeu caracteres. Qualquer outro resto é válido, de modo que uma string cortada exatamente no limite de um grupo parece correta e decodifica para menos bytes do que foram enviados; só um tamanho conhecido, um checksum ou uma assinatura podem pegar isso.
Última atualização 28 de outubro de 2026
