Guia do codificador e decodificador Base64: UTF-8, Base64url e erros

Como codificar ou decodificar texto

Abra o codificador e decodificador Base64 e cole texto ou uma cadeia codificada. Deixe a opção Base64 seguro para URL desativada para usar o alfabeto padrão ou ative-a quando o formato de destino exigir Base64url. Codificar converte toda a entrada em Base64; Decodificar a converte de volta em texto UTF-8. Apenas digitar não inicia uma conversão.

Leia o resultado antes de usar Copiar resultado ou Baixar. Usar resultado como entrada substitui o conteúdo do editor por um resultado que respeite o limite de entrada; depois você pode escolher a ação inversa para verificar a ida e volta. Editar a entrada ou mudar as opções de conversão invalida o resultado anterior. Quebrar linhas altera a disposição visual, não os caracteres codificados nem as quebras de linha do conteúdo.

• Comece com um exemplo conhecido, como foo e Zm9v, antes de investigar um valor da aplicação.
• Escolha o alfabeto exigido pela aplicação; apenas letras e dígitos comuns podem não revelar qual variante uma cadeia usa.
• Guarde o original se for necessário preservar cada byte. Importação de texto, codificação de caracteres e quebras de linha extras podem alterar o que você codifica.

O que Base64 faz com os bytes

Base64 divide cada grupo de três bytes em quatro valores de seis bits e associa esses valores a caracteres do alfabeto. Um último grupo incompleto exige tratamento especial e pode usar preenchimento. As letras visíveis representam os bytes de entrada; não são um novo idioma nem uma chave secreta.

Estes exemplos com o alfabeto padrão incluem a cadeia vazia e terminações ASCII de um, dois e três bytes. Os espaços e as quebras de linha do texto que você codifica são bytes reais e alteram o resultado. Decodificar a mesma codificação canônica restaura o texto UTF-8 original, incluindo esses caracteres.

RFC 4648: Base64, Base64url, preenchimento e codificação canônica

Base64 padrão e Base64url

As duas variantes usam letras e dígitos. Base64 padrão usa + e / como os dois últimos símbolos do alfabeto; Base64url usa - e _. O ToolMellow acrescenta os = finais necessários no modo padrão e os omite no modo seguro para URL. Por exemplo, o emoji acima se torna 8J-YgA no modo seguro para URL.

O decodificador aceita somente o alfabeto selecionado. Ambos os modos aceitam entradas sem preenchimento ou com preenchimento opcional colocado corretamente. Base64url não proíbe o preenchimento de maneira universal: o protocolo que o utiliza determina se ele é obrigatório, permitido ou omitido. Selecione o formato necessário em vez de presumir que todas as URLs ou todos os tokens seguem a mesma convenção.

RFC 4648: Base64, Base64url, preenchimento e codificação canônica

Unicode, emojis e decodificação UTF-8

O texto passa por UTF-8, portanto acentos, chinês, árabe e emojis podem ser preservados em uma conversão de ida e volta quando a entrada é Unicode bem formado. O comprimento de uma string JavaScript conta unidades de código UTF-16; o comprimento em bytes UTF-8 é diferente. O emoji 😀 ocupa duas unidades UTF-16, mas quatro bytes UTF-8, que produzem oito caracteres Base64 com preenchimento.

A codificação rejeita um substituto Unicode sem par. A decodificação rejeita UTF-8 inválido em vez de substituir silenciosamente bytes incorretos. Um BOM UTF-8 codificado no início é preservado como U+FEFF na string decodificada; ele pode ser invisível no editor. Texto válido também pode conter caracteres de controle ou diferentes formas de normalização Unicode. Base64 não normaliza o texto nem torna sua execução segura.

RFC 3629: codificação de caracteres UTF-8WHATWG Encoding: TextEncoder, TextDecoder e tratamento do BOMECMAScript: comprimento de strings e isWellFormed

Preenchimento, espaços em branco e bits não usados

O preenchimento tem no máximo dois caracteres = no final, e o comprimento com preenchimento deve ser divisível por quatro. O decodificador também permite entrada sem preenchimento com uma terminação válida, mas um comprimento restante de um caractere não pode representar um byte completo. Zg== e Zg são ambos decodificados como f; Zg= está malformado. Uma entrada vazia tem um resultado vazio válido.

Antes de decodificar, o ToolMellow remove somente TAB, LF, CR e SPACE. Rejeita avanço de página, tabulação vertical, espaço não separável e outros espaços em branco Unicode. O limite da entrada original é verificado antes dessa remoção. Portanto, esse comportamento é mais restrito do que uma promessa geral de ignorar todos os espaços em branco.

Nesta ferramenta, os bits não usados no último símbolo do alfabeto devem ser zero. O decodificador verifica se recodificar os bytes decodificados corresponde à entrada normalizada sem preenchimento. Zh== é rejeitado, embora um decodificador permissivo possa produzir o mesmo byte que a forma canônica Zg==. A RFC 4648 permite essa rejeição mais rigorosa; a aceitação por outro decodificador não prova que a entrada seja canônica.

RFC 4648: Base64, Base64url, preenchimento e codificação canônicaWHATWG Infra: decodificação Base64 permissivaWHATWG HTML: atob e btoa

Quanto Base64 aumenta o tamanho e o que cabe

Para n bytes de entrada, o comprimento de Base64 com preenchimento é de 4 × ceil(n / 3) caracteres. Zero bytes produzem zero caracteres; um byte produz quatro, dois produzem quatro e três produzem quatro. O aumento se aproxima de um terço para entradas grandes, mas não é exatamente 33% para todos os valores. A saída segura para URL sem preenchimento remove o último ou os dois últimos caracteres de preenchimento, quando aplicável.

Conte bytes UTF-8 na fórmula de tamanho e unidades de código UTF-16 no limite do editor. A ferramenta permite até 1,000,000 unidades de código de entrada antes de remover espaços em branco ao decodificar. Ela não aplica o mesmo teto à saída: um milhão de bytes ASCII produzem 1,333,336 caracteres com preenchimento. Copiar e Baixar continuam disponíveis, mas Usar resultado como entrada não pode carregar um resultado acima do limite de entrada.

RFC 4648: Base64, Base64url, preenchimento e codificação canônicaWHATWG Encoding: TextEncoder, TextDecoder e tratamento do BOMECMAScript: comprimento de strings e isWellFormed

Abrir um arquivo de texto não equivale a codificar um arquivo binário

O controle de arquivos lê um arquivo local como texto UTF-8 por meio de File.text(). Arquivos com 4,000,000 bytes ou mais são rejeitados; texto com mais de 1,000,000 unidades UTF-16 também é rejeitado após a leitura. A aplicação não envia o arquivo para realizar essa conversão. A extensão do nome não comprova que seus bytes sejam texto UTF-8.

A leitura comum de um arquivo como texto remove um BOM UTF-8 inicial e substitui sequências UTF-8 malformadas. Isso pode alterar os bytes originais antes da codificação. Esse comportamento difere do decodificador Base64, que rejeita UTF-8 malformado e preserva U+FEFF decodificado. Para imagens, PDFs, bytes arbitrários ou recuperação exata dos bytes de um arquivo, use a ferramenta separada Base64 para arquivo quando adequado; este espaço de texto não é um codificador de arquivos binários brutos.

API File do W3C: leitura de Blob como textoWHATWG Encoding: TextEncoder, TextDecoder e tratamento do BOM

Por que meu Base64 é inválido?

Primeiro identifique o formato esperado e se o valor deve ser decodificado em texto. Remova de forma deliberada a sintaxe da aplicação que envolve o valor, em vez de apagar caracteres desconhecidos até funcionar. Este decodificador não extrai automaticamente conteúdos de URLs de dados, segmentos de tokens, strings JSON entre aspas ou HTML. Esses formatos envolventes têm suas próprias regras de análise e validação.

Se o alfabeto e a estrutura forem válidos, mas os bytes decodificados não forem UTF-8, os dados podem ser um arquivo binário ou usar outra codificação de caracteres. É um erro devido ao escopo textual da ferramenta, não uma prova de que os bytes Base64 estejam corrompidos. Se o acesso à área de transferência estiver indisponível, selecione o resultado e copie manualmente. Um navegador incompatível ou um worker bloqueado também pode impedir a conversão; use um navegador atual compatível e leia o erro exibido.

RFC 4648: Base64, Base64url, preenchimento e codificação canônicaRFC 3629: codificação de caracteres UTF-8

Base64url, codificação percentual e URLs de dados

Base64url e codificação percentual resolvem problemas diferentes. A codificação percentual representa certos bytes de uma URL com sequências que usam %; Base64url representa uma sequência completa de bytes com seu próprio alfabeto. Um sinal de mais vira um espaço especificamente na análise de application/x-www-form-urlencoded, não em todas as URLs. Use o codificador e decodificador de URLs para essa tarefa separada.

Uma URL de dados tem o esquema data:, um tipo de mídia opcional e uma vírgula antes do conteúdo, com um marcador Base64 quando aplicável. Colar toda essa estrutura no decodificador de texto faz a verificação do alfabeto falhar. Extraia o conteúdo pretendido com a ferramenta adequada e considere se ele é texto ou dados binários. Base64 não torna confiável um script incorporado, um documento ou um arquivo baixado.

WHATWG URL: análise de formulários codificados para URLRFC 2397: esquema de URL de dados

Segmentos JWT e HTTP Basic são dados de protocolo

JWS compacto usa três segmentos separados por pontos; JWE compacto usa cinco. Decodificar um segmento textual de um JWT pode revelar JSON, mas não verifica uma assinatura, não descriptografa conteúdo criptografado, não valida a expiração e não estabelece autorização. Um segmento de assinatura pode conter bytes arbitrários e não precisa ser decodificável em UTF-8. Siga o protocolo real do token e use uma biblioteca de verificação mantida na sua aplicação.

Credenciais HTTP Basic usam uma representação Base64 de uma sequência de nome de usuário e senha, com regras de codificação de caracteres próprias do protocolo. Base64 não acrescenta confidencialidade. Esta ferramenta de texto UTF-8 não comprova que uma credencial corresponda à interpretação de todos os servidores. Não publique credenciais reais nos exemplos e use o transporte seguro e o procedimento de autenticação exigidos.

RFC 7515: serialização compacta de JSON Web SignatureRFC 7516: serialização compacta de JSON Web EncryptionRFC 7617: autenticação HTTP Basic

Base64 não é criptografia, hash nem compressão

Qualquer pessoa que tenha um valor Base64 pode reverter a representação sem uma chave secreta. Criptografia exige uma construção criptográfica e gerenciamento de chaves; um hash produz um resumo com finalidades e propriedades diferentes. Converter uma senha em Base64 não é uma forma adequada de armazená-la. A ferramenta separada de hash produz resumos, não um sistema de armazenamento de senhas nem um substituto da criptografia.

Base64 também aumenta o tamanho dos bytes em vez de comprimi-los. Pode transportar bytes criptografados, comprimidos ou assinados, mas não cria essas proteções por si só. Defina o que sua aplicação precisa antes de acrescentar uma camada de codificação e mantenha segredos fora de exemplos compartilhados, capturas de tela e resultados baixados.

RFC 4648: Base64, Base64url, preenchimento e codificação canônica

Copiar, baixar, verificar a ida e volta e limpar

Baixar salva o resultado como texto UTF-8 em toolmellow-result.txt. Isso não é uma reconstrução binária nem um relatório de conversão. Um resultado vazio válido também habilita Copiar resultado e Baixar. Para uma verificação simples, codifique um texto conhecido, use o resultado como entrada quando ele couber, decodifique com o alfabeto correspondente e compare com o texto original.

Limpar remove a entrada, o resultado, os erros, o conteúdo de busca e substituição e o histórico do editor, mantendo as escolhas de Base64 seguro para URL e Quebrar linhas. Atualizar ou fechar o espaço de trabalho descarta os dados de trabalho em memória; arquivos já baixados permanecem no dispositivo. Limpar não garante apagamento forense da memória do navegador ou do sistema operacional.

O que processamento local significa e quais são seus limites

A conversão é executada em um worker do navegador. A aplicação não envia texto colado, conteúdo de arquivos selecionados ou resultados da conversão a um servidor de conversão. A entrada de trabalho fica na página atual, em vez de ser salva no histórico de uma conta. Consulte a página de privacidade do site para entender o armazenamento e as transferências temporárias.

Carregar o site ainda gera solicitações de rede. A infraestrutura de hospedagem recebe metadados comuns de conexão e requisições, e o site público usa Google Analytics para visitas às páginas, com cookies e informações sobre o navegador e o dispositivo. Conversão local não significa anonimato nem promete ausência de tráfego de rede ou de registros na infraestrutura. Arquivos baixados e um resultado copiado manualmente podem sair do espaço de trabalho pelas suas próprias ações.

Incorpore a ferramenta Base64 com seu link de atribuição

Abra a seção de integração abaixo do espaço de trabalho, escolha o idioma da página e copie ou baixe o trecho HTML fornecido. Cole-o em uma área HTML que permita iframes e scripts externos. O trecho inclui o iframe do espaço ToolMellow, seu script de ajuste de tamanho e um link visível de volta para a página da ferramenta ToolMellow no idioma correspondente. Mantenha esse link de atribuição.

Pré-visualize a incorporação e confira telas estreitas. Ela mantém o mesmo escopo de texto e os mesmos limites de entrada; não é uma API remota de conversão nem um codificador de arquivos binários. O acesso à área de transferência depende das permissões do navegador, e sua plataforma deve permitir os recursos externos. O link fornecido usa nofollow e noopener; sua presença não garante melhorias no posicionamento em buscadores.

Perguntas frequentes

Fontes e leituras complementares

• RFC 4648: Base64, Base64url, preenchimento e codificação canônica
• RFC 3629: codificação de caracteres UTF-8
• WHATWG Encoding: TextEncoder, TextDecoder e tratamento do BOM
• ECMAScript: comprimento de strings e isWellFormed
• WHATWG Infra: decodificação Base64 permissiva
• WHATWG HTML: atob e btoa
• API File do W3C: leitura de Blob como texto
• WHATWG URL: análise de formulários codificados para URL
• RFC 2397: esquema de URL de dados
• RFC 7515: serialização compacta de JSON Web Signature
• RFC 7516: serialização compacta de JSON Web Encryption
• RFC 7617: autenticação HTTP Basic