Decodificar Base64

Por ordem de frequência: um JWT, um cabeçalho de Basic Auth, o valor de um secret do Kubernetes, um payload de webhook. Três desses quatro são credenciais, e o quarto costuma carregar dados de pessoas.

É por isso que esta página não tem servidor atrás. Não é postura: é consequência direta do uso que se dá a ela. Uma ferramenta que decodifique isso remotamente já viu a credencial e a tem no log de requisições, e nenhum aviso legal muda esse fato.

Um JWT é cabeçalho, payload e assinatura, separados por pontos e cada parte em Base64 seguro para URL. As duas primeiras são JSON e se leem direto; a terceira é a assinatura e não é texto, então decodificar ela não devolve nada aproveitável.

A consequência incômoda é que o conteúdo de um token não é secreto: qualquer pessoa que o tenha consegue ler a quem ele pertence, quando expira e quais permissões declara. A assinatura impede alterar, não impede ler. Colocar dado pessoal no payload de um JWT é, portanto, publicá-lo para quem quer que veja o token.

Uma string em Base64 pode conter um PNG, um PDF ou um ZIP tão bem quanto uma frase. Ler esses bytes como texto produz símbolos de substituição, e muitas ferramentas devolvem isso do mesmo jeito, de forma que parece que o Base64 estava quebrado quando ele estava perfeito.

Aqui a distinção é feita: se a string é Base64 válido mas os bytes não formam texto, isso é dito, junto com quantos bytes são. É a resposta útil, porque encerra a caça a um erro de codificação que não existe e transfere a pergunta para que tipo de dado aquilo é de verdade.

Os JWT tiram os sinais de igual do fim de propósito, porque a especificação do Base64 seguro para URL permite. Muitas bibliotecas, em compensação, se recusam a decodificar sem padding e devolvem um erro que não explica nada.

Este decodificador repõe o padding sozinho quando falta, então um token copiado de um cabeçalho é lido como está. Se o seu código falha com um valor que aqui funciona, essa costuma ser exatamente a razão, e a solução é completar até o próximo múltiplo de quatro antes de entregar à biblioteca.

O alfabeto padrão usa `+` e `/`; o seguro para URL usa `-` e `_`. Aqui os dois são aceitos sem perguntar, porque saber qual deles chegou até você não deveria ser pré-requisito para ler uma string que alguém colou no seu chat.

Vale a pena saber no outro sentido, isso sim. Se você está gerando um valor que vai viajar num endereço e usa o alfabeto padrão, a barra quebra o caminho e o sinal de mais é lido como espaço: o valor chega, mas alterado, e a falha aparece bem longe de onde foi criada.

O e-mail quebra o Base64 em linhas de 76 caracteres e os certificados PEM em 64, porque os padrões deles exigem. Um valor copiado de um arquivo `.pem` ou do corpo de um e-mail chega, portanto, com quebras de linha dentro.

Elas são ignoradas, junto com os espaços soltos que aparecem quando se copia de um terminal. Não é preciso limpar nada antes: se alguma coisa colada não faz parte do alfabeto, isso é dito em vez de decodificar pela metade e devolver um resultado que parece bom.

Uma string decodificar não quer dizer que o conteúdo dela esteja correto. Um JWT expirado é lido tão bem quanto um vigente, e uma assinatura falsa decodifica exatamente igual a uma boa, porque conferir a assinatura exige a chave e esta página não a tem nem a quer.

Serve para ler, não para confiar. Se o que você precisa é saber se um token é válido, quem tem que dizer isso é o sistema que o emitiu; o que esta página responde é o que ele diz, que é outra pergunta e normalmente a primeira.

Se aparecem losangos com uma interrogação no resultado, os bytes não formavam UTF-8 válido. Pode ser que sejam dados binários — um arquivo, não um texto — ou que o texto tenha sido codificado originalmente em Latin-1 e esteja sendo lido agora como UTF-8.

Distinguir os dois casos é fácil pelo padrão: um arquivo dá lixo desde o primeiro byte, enquanto um texto em Latin-1 se lê bem exceto justamente nos acentos e nas cedilhas. Esse segundo caso é o clássico dos dados brasileiros mal migrados, e aparece num banco com a collation errada muito antes de aparecer num Base64.

Um `Secret` do Kubernetes guarda os valores dele em Base64, e isso confunde muita gente: não está criptografado em repouso a menos que isso seja configurado à parte, e qualquer pessoa com permissão de ler o recurso lê a credencial em um passo.

Por isso vale ter claro o que protege o quê. O Base64 está ali para que valores binários caibam em YAML, não para escondê-los. A proteção real são as permissões do cluster e, se necessário, a criptografia em repouso — e um valor de `Secret` colado numa ferramenta online é uma credencial que saiu do cluster.

Qualquer texto formado só por letras, dígitos e os dois símbolos do alfabeto, com comprimento múltiplo de quatro, decodifica para alguma coisa. Um hash MD5 de 32 caracteres cumpre esses requisitos, e um UUID sem hífen também — os dois saem daqui como bytes que não são texto, e não porque estivessem quebrados.

A conclusão prática é que «decodificou» não é uma verificação de formato. Se o seu código usa uma tentativa de decodificação para decidir se um campo é Base64, ele vai aceitar valores que nunca foram, e o erro só aparece depois, quando alguém tenta usar o conteúdo. O que responde a essa pergunta é o contexto de onde o valor veio, e não o decodificador.

De todas as páginas deste site, esta é a que mais recebe credencial e dado pessoal: payloads de webhook com nome e endereço, tokens que identificam uma pessoa, despejos de configuração. Como a decodificação acontece na página, nada disso é compartilhado conosco.

É o que torna a ferramenta utilizável num ambiente com política interna séria. Um serviço que decodificasse remotamente teria recebido o dado pessoal e o teria nos logs, e essa é exatamente a hipótese que essas políticas existem para evitar. O painel de rede demonstra isso em um minuto.

Codificar tem a sua própria página porque é outro momento. Quem codifica está montando algo e precisa decidir o alfabeto; quem decodifica está lendo algo que chegou e precisa saber o que fazer quando o resultado não é texto.

O motor é o mesmo e as explicações não são. Uma página conjunta com um seletor obrigaria cada visitante a atravessar a metade que não serve, e as duas seções que de fato resolvem o problema dele ficariam diluídas entre as que não resolvem.