Ferramenta decodificadora Base64 online

1. 1

   Cole o Base64

   Cole a string na caixa de entrada. Quebras de linha, preenchimento ausente e caracteres base64url são todos tratados, e você pode colar um data URI, um bloco PEM ou um JWT inteiros — o invólucro é detectado e removido automaticamente.

2. 2

   Leia o resultado

   A saída aparece enquanto você digita até 256 KB; acima disso, decodifica ao clicar em Decodificar. O painel indica o formato encontrado, o tipo de arquivo reconhecido nos bytes e o conjunto de caracteres usado para mostrar texto.

3. 3

   Ajuste se a detecção falhou

   Alterne a visualização entre texto, hexadecimal e ASCII imprimível, escolha um conjunto de caracteres específico se o detectado produziu caracteres de substituição, ou ative o modo estrito para que entradas malformadas sejam recusadas em vez de reparadas.

4. 4

   Copie ou baixe

   Copie o texto, ou baixe os dados com a extensão que os próprios bytes justificam — um PNG decodificado é salvo como .png, não como .bin. Tudo é processado no seu dispositivo e nada é enviado.

Cinco configurações, e cada uma existe porque uma carga real precisou dela. Nenhuma está atrás de um plano pago — um decodificador que retém a decodificação não está limitado, está com defeito.

Formato de entrada

Deixe em Auto e cole o que for. A ferramenta procura, por ordem, um prefixo data URI, um bloco de armadura OpenPGP, um cabeçalho PEM e um JWT de três partes, e caso contrário trata a entrada como uma carga simples. Escolher um formato explicitamente o transforma numa afirmação: se escolher PEM e a entrada não tiver linha BEGIN, é isso que a ferramenta informa, em vez de decodificar outra coisa. Escolher Padrão ou Seguro para URL fixa ainda o alfabeto, por isso, com o modo estrito ligado, uma carga que use o outro é recusada exatamente no caractere onde diverge.

Modo estrito

Desligado por padrão, porque a tarefa do dia a dia é ler uma string que alguém enviou para você, e recusá-la por causa de um = ausente não ajuda ninguém. Ligado, quatro coisas passam a ser erros em vez de reparações: espaços fora de um formato com quebras, preenchimento ausente ou errado, um alfabeto misturado, e um grupo final cujos bits não usados não são zero. Este último merece ser conhecido — tem uma seção própria mais abaixo, e nenhum outro decodificador na web informa isso.

Dividir a entrada

Um mecanismo, dois usos. «Cada linha» decodifica separadamente uma lista de cargas independentes e as mostra como resultados distintos, que é o que se quer quando um arquivo de registro ou uma coluna de banco de dados tem um valor Base64 por linha. «Segmentos JWT» divide nos pontos, para que o cabeçalho e a carga de um token decodifiquem cada um por si e uma assinatura que não é texto legível não estrague o resto. Auto escolhe a segunda quando a entrada é um JWT e deixa tudo o resto em paz.

Mostrar resultado como

Auto mostra texto para uma carga de texto e um despejo hexadecimal para todo o resto, com base no que os bytes realmente são e não em se um decodificador de texto produziu alguma coisa. Você pode mudar essa escolha: hexadecimal é a visualização certa para uma carga binária que está inspecionando, ASCII imprimível ajuda a detectar strings embutidas dentro de um binário, e forçar Texto é como se verifica uma carga que o detector classificou mal. Trocar de visualização é instantâneo porque volta a mostrar bytes já decodificados.

Conjunto de caracteres

Auto lê primeiro uma marca de ordem de bytes, depois qualquer conjunto declarado por um data URI, depois testa se os bytes são UTF-8 válido, e recorre a Windows-1252 como palpite assumido. Se o resultado tiver caracteres de substituição, o painel diz quantos, e escolher o conjunto certo da lista resolve isso sem voltar a decodificar o Base64.

O Base64 é uma só codificação, mas chega embrulhado em pelo menos sete coisas diferentes. Um decodificador que só aceita uma carga simples rejeita a maior parte do que as pessoas realmente têm na área de transferência.

• Padrão — o alfabeto do RFC 4648 — A–Z, a–z, 0–9, + e /, preenchido com =. O que a maioria dos codificadores emite.
• Seguro para URL (base64url) — o mesmo, com - e _ em vez de + e /, para que a string sobreviva dentro de um URL ou de um nome de arquivo. Normalmente sem preenchimento. Detectado e decodificado sem nenhuma configuração.
• MIME — Base64 padrão quebrado em 76 colunas, como nos corpos de e-mail. As quebras de linha são removidas; no modo estrito são o único espaço que continua legal, porque o formato é definido por elas.
• PEM — uma carga entre linhas -----BEGIN X----- e -----END X-----, como usam certificados, chaves privadas e CSR. Os rótulos têm de coincidir nas duas pontas, e um bloco cujo BEGIN e END divergem é informado como danificado em vez de decodificado em silêncio.
• ASCII-Armor do OpenPGP — o primo do PEM, com cabeçalhos de armadura opcionais e uma linha de soma =CRC24. A soma é verificada — é a única verificação de integridade que qualquer variante de Base64 traz, e uma ferramenta que a remove sem olhar jogou fora a única prova que o formato oferece.
• Data URI — data:image/png;base64,…, que é o que se obtém ao copiar uma imagem embutida de CSS ou das ferramentas de desenvolvedor. O prefixo é removido, e o tipo de mídia e conjunto de caracteres que declara são usados em vez de adivinhados.
• JWT — três segmentos base64url separados por pontos. Dividido nos pontos para que o cabeçalho e a carga decodifiquem como o JSON que são — incluindo tokens com segmento de assinatura vazio, que alg:none produz e que uma divisão mais estrita recusaria.

Esta é a parte que a maioria dos decodificadores Base64 pula, e pulá-la é a razão de tantos entregarem a você uma tela de pontos de interrogação. O Base64 não diz nada sobre o seu conteúdo. Assim que os bytes existem, porém, eles próprios costumam dizê-lo: quase todos os formatos binários começam com uma assinatura, e lê-la é barato.

São verificadas cerca de quarenta assinaturas, cobrindo imagens (PNG, JPEG, GIF, WebP, BMP, ICO, TIFF, AVIF, HEIC), documentos (PDF, RTF), arquivos (ZIP, gzip, bzip2, xz, zstd, 7z, RAR), áudio e vídeo (MP3, FLAC, Ogg, WAV, MP4, WebM, AVI), fontes (TTF, OTF, WOFF, WOFF2) e executáveis. Os formatos baseados em ZIP são refinados mais um passo lendo o nome da primeira entrada dentro do arquivo, por isso um .docx decodificado é oferecido como .docx e não como .zip, e um arquivo OpenDocument é identificado pelo tipo de mídia que a sua própria entrada mimetype transporta. Quando nada corresponde, a ferramenta testa se os bytes são sequer texto — um byte NUL é o sinal, com uma exceção para UTF-16, que por construção é metade bytes NUL — e texto que começa com uma chave só é rotulado JSON se de fato for analisável.

Daqui decorrem duas coisas visíveis na interface. O botão de baixar oferece o arquivo com a extensão que os próprios bytes justificam, por isso um PNG decodificado é salvo como .png e abre com um duplo clique. E uma carga binária nunca passa por um decodificador de texto para produzir uma página de caracteres de substituição U+FFFD: vai direto para a visualização hexadecimal, e o painel diz o que encontrou.

Esta é a razão mais comum para uma decodificação «parecer errada», e não é um defeito do decodificador. O Base64 codifica bytes. Não tem campo para uma codificação, nem cabeçalho, nem convenção para isso. Qualquer ferramenta que mostre texto a você escolheu uma codificação sozinha, e a maioria não diz qual.

• Uma marca de ordem de bytes é uma afirmação — se os bytes decodificados começarem com uma BOM, o produtor disse qual é a codificação, e é essa que se usa. São reconhecidos UTF-8, UTF-16 nas duas ordens e UTF-32 nas duas.
• Um data URI pode declarar uma — data:text/plain;charset=windows-1251;base64,… nomeia o seu próprio conjunto, e é respeitado — mas fica abaixo de uma BOM, porque uma BOM está nos dados e o parâmetro é apenas uma afirmação sobre eles.
• UTF-8 válido é quase uma prova — o UTF-8 tem estrutura suficiente para que um documento de qualquer comprimento dificilmente seja válido por acaso. Se os bytes decodificam estritamente como UTF-8, é isso que são.
• ASCII puro não prova nada — o ASCII é UTF-8 válido e válido em qualquer conjunto de um byte, por isso a pergunta não tem resposta. A ferramenta diz «ambíguo» em vez de afirmar uma detecção segura que os dados não sustentam.
• Caso contrário é um palpite, e é assinalado como tal — uma carga que não é UTF-8 válido está em alguma codificação de um byte, e os bytes não podem dizer qual. O Windows-1252 é de longe o mais comum, por isso é o recurso — mostrado como palpite, com a lista completa a um clique.

São oferecidos trinta e um conjuntos de caracteres, e a lista é construída perguntando ao navegador quais suporta de fato, em vez de enumerar os que devia suportar. O UTF-32 é a exceção: nenhum navegador o implementa no seu decodificador de texto, por isso é decodificado aqui diretamente — e é por isso que aparece na lista.

O Base64 empacota três bytes em quatro caracteres. Quando o comprimento da entrada não é múltiplo de três, o grupo final fica curto — e alguns bits do seu último caractere não pertencem a byte nenhum.

Num grupo final de dois caracteres, sobram os últimos quatro bits. Num de três, os últimos dois. Um codificador conforme escreve zeros aí. Nada obriga um decodificador a olhar, e praticamente nenhum o faz: QQ== e QR== decodificam ambos no único byte 0x41, em silêncio, em todos os navegadores, em todas as ferramentas de linha de comando e em todos os sites que testamos. Uma dessas strings veio de um codificador e a outra estava corrompida ou editada à mão, e nenhuma ferramenta as distingue.

O modo estrito verifica. É informado como erro com o modo estrito ligado e como aviso quando está desligado, por isso os bytes continuam lá para serem vistos — a questão não é recusar os dados, é que você saiba que a string não foi produzida da forma que afirma. O mesmo vale para uma carga que mistura os dois alfabetos: - e _ nunca colidem com + e /, por isso decodifica sem ambiguidade, mas um dos dois está fora do lugar e provavelmente alguém devia saber.

Cada recusa indica o índice do caractere, a linha e a coluna do problema, e qual era o caractere. Nenhuma das duas funções Base64 do navegador informa uma posição, e nenhuma ferramenta concorrente também — numa carga de quatro megabytes com um caractere solto, «inválido» não é um diagnóstico.

• Base64 inválido — um caractere fora do alfabeto. No modo tolerante isto só é informado para caracteres genuinamente estranhos — os espaços e quebras de linha são removidos antes. Um espaço inquebrável, que é o que copiar de uma página web renderizada muitas vezes produz, conta como estranho, e a posição mostra exatamente onde caiu.
• Truncada — a carga tem um grupo final de um caractere, algo que nenhuma entrada pode produzir. É o único sinal inequívoco de «a string foi cortada» que o Base64 tem.
• Dados depois do preenchimento — há caracteres depois dos sinais =. Quase sempre duas strings Base64 juntas, que qualquer decodificador tolerante transformará alegremente em lixo plausível.
• Preenchimento ausente ou inesperado — só no modo estrito. Os caracteres = faltam, são demais, ou não têm o comprimento que o próprio comprimento da carga exige.
• Espaços não permitidos — só no modo estrito, e só fora dos formatos com quebras. As quebras de linha dentro de MIME, PEM e PGP fazem parte desses formatos e continuam legais.
• Alfabeto errado ou misturado — só no modo estrito. A carga usa caracteres do alfabeto que não selecionou, ou de ambos.

O Base64 é uma codificação, não uma criptografia nem uma fronteira de segurança. Serve para mover bytes por canais que só aceitam texto, e os bytes do outro lado são os que alguém lá pôs.

• A saída decodificada é entrada não confiável — uma carga pode decodificar num script, num executável ou em marcação feita para rodar em outro lugar. Ter sido Base64 não torna nada seguro, e ter chegado codificado às vezes é exatamente o objetivo.
• Não cole segredos que não colaria em outro lugar — esta página roda inteiramente no seu dispositivo e não envia nada, o que você pode verificar com as ferramentas de rede do navegador — mas o hábito de colar credenciais em formulários web não vale a pena adquirir, porque a maioria das páginas parecidas com esta de fato envia.
• A carga de um JWT não é verificada — dividir um token e decodificar os seus segmentos mostra o que ele afirma. Não verifica a assinatura, e qualquer pessoa pode produzir um token que diga qualquer coisa. Leia-o como uma afirmação, nunca como um fato.
• Uma soma de armadura não é uma assinatura — o CRC-24 de um bloco PGP detecta corrupção acidental. Não é uma verificação criptográfica e não diz quem produziu o bloco.

O Base64 não chega só pela área de transferência. É armazenado em arquivos .txt e .b64, em certificados .pem e blocos de armadura .asc, e embutido em documentos .json, .xml e .eml — tudo isso pode ser solto na página.

O que o plano grátis inclui

Até 25 MB de Base64, uma entrada por vez, e todas as capacidades da ferramenta: os sete formatos de entrada, os trinta e um conjuntos de caracteres, o modo estrito, as visualizações hexadecimal e ASCII, a detecção do tipo de arquivo, o download tipado e os modos de divisão. O limite é de escala, nunca de se a ferramenta funciona — 25 MB de Base64 são cerca de 18,75 MB de dados decodificados, uma carga grande por qualquer medida normal.

O que o Pro acrescenta

Até vinte entradas por vez, todas baixadas num único arquivo, e o limite de tamanho substituído pelo que o seu dispositivo aguenta de fato em vez de um número fixo maior. A compressão dentro do arquivo é escolhida por arquivo conforme o que a carga se revelou ser, por isso um lote de imagens decodificadas é armazenado em vez de recomprimido sem sentido, enquanto um lote de JSON decodificado é comprimido.

Várias codificações se parecem o suficiente com Base64 para serem confundidas com ele, e um decodificador que as aceite mesmo assim produz disparates convincentes. Se a saída for lixo e o conjunto de caracteres não for o problema, verifique se a entrada é uma destas.

• Codificação por porcentagem — %20 e %E2%9C%93 são codificação de URL, não Base64. Use antes o codificador e decodificador de URL.
• Hexadecimal — uma string só com 0–9 e a–f, de comprimento par, é muito mais provavelmente hexadecimal do que Base64 — e hexadecimal também é Base64 válido, que é precisamente por isso que o engano produz uma decodificação em vez de um erro.
• Base32 — maiúsculas A–Z e 2–7, preenchidas com =. Compartilha o caractere de preenchimento e mais nada.
• Um hash — um resumo MD5, SHA-1 ou SHA-256 não são dados codificados e não podem ser decodificados de volta em nada. É uma impressão digital de sentido único; use o gerador de hash para produzir uma.
• Texto já decodificado — as palavras comuns são feitas de caracteres Base64, por isso uma frase colada num decodificador «decodificará» em bytes. Se o resultado for binário e a entrada era legível, a entrada não estava codificada.

Recorra ao decodificador quando já tem uma string Base64 e precisa do que está lá dentro. Use o codificador para o sentido contrário.

• Inspecionar um campo Base64 numa resposta de API, num corpo de webhook ou numa linha de registro.
• Ler o cabeçalho e a carga de um JWT para ver o que um token afirma.
• Retirar uma imagem ou uma fonte de um data URI embutido em CSS, HTML ou SVG.
• Verificar o que um certificado PEM ou um bloco de armadura PGP contém de fato.
• Recuperar texto armazenado como Base64 numa coluna de banco de dados ou num arquivo .env.
• Confirmar com o modo estrito que um codificador produziu saída conforme.
• Transformar uma carga Base64 de volta num arquivo real e abrível com a extensão correta.

O decodificador usa o caminho Base64 que o seu navegador fornecer — os mais recentes têm um nativo e os mais antigos recorrem a outro que existe em todo lugar e produz saída idêntica byte a byte. Não há nada para configurar nem para instalar. Os conjuntos de caracteres vêm do navegador, por isso a lista exata varia muito ligeiramente entre motores; a ferramenta mostra o que o seu suporta de fato, não o que devia suportar.

A decodificação roda fora da thread principal, no seu dispositivo, usando o caminho Base64 mais rápido que o seu navegador oferece. Medido num computador desktop, uma carga de 25 MB decodifica em cerca de 170 milissegundos de ponta a ponta, incluindo descobrir o que são os bytes.

• Codificador Base64
• Codificador/Decodificador Base64
• Codificador/Decodificador de URL
• Gerador de hash
• Gerador de UUID
• Leitor de código QR
• Formatador JSON
• Validador JSON
• Minificador JSON
• XML para JSON
• Conversor de maiúsculas
• Aparador de texto
• Conversor de cores
• Todos os conversores