Ferramenta online de codificação e decodificação Base64

1. 1

   Escolha um sentido

   Selecione Codificar para transformar conteúdo em Base64, ou Decodificar para recuperar o texto ou o arquivo original a partir de uma string Base64.

2. 2

   Forneça a entrada

   Digite ou cole na caixa, ou solte um arquivo. A codificação aceita qualquer arquivo; a decodificação aceita arquivos de texto com Base64, incluindo certificados PEM com as linhas BEGIN e END.

3. 3

   Defina o formato

   Escolha o alfabeto padrão ou o seguro para URL, decida se mantém o preenchimento, quebre em 64 ou 76 caracteres, e ative a opção de URI de dados se o resultado for para HTML ou CSS.

4. 4

   Verifique o resultado

   O texto digitado é convertido enquanto você digita. O painel indica o tamanho de entrada, o de saída e a sobrecarga, e ao decodificar nomeia o alfabeto detectado, a codificação de texto usada e o tipo de arquivo encontrado.

5. 5

   Copie ou baixe

   Copie o resultado para a área de transferência, baixe-o com um nome adequado ao que realmente é, ou baixe um lote inteiro num único ZIP. Tudo roda no seu dispositivo, não nos nossos servidores.

Nove configurações, e todas existem porque algum formato real precisa delas. Isto é o que cada uma muda e quando importa.

Alfabetos padrão e seguro para URL

O Base64 precisa de sessenta e quatro caracteres imprimíveis. Cinquenta e duas letras e dez algarismos chegam a sessenta e dois, e os dois últimos são aqueles em que as duas variantes discordam. O alfabeto padrão do RFC 4648 seção 4 usa o sinal de mais e a barra, o que serve para corpos de mensagem e campos de API. A variante segura para URL da seção 5 usa hífen e sublinhado, porque uma barra divide um caminho e um mais significa espaço numa string de consulta. Todo o resto é idêntico, e é por isso que uma carga feita apenas de letras e algarismos é decodificada da mesma forma com qualquer um deles.

O preenchimento e quando o retirar

O Base64 trabalha em grupos de três bytes, por isso uma carga cujo comprimento não seja múltiplo de três acaba com um grupo incompleto. Os sinais de igual dizem quão incompleto. O Base64 padrão os mantém; o seguro para URL normalmente não, porque um JSON Web Token põe três segmentos Base64 seguidos separados por pontos e o preenchimento atrapalharia. Retirar o preenchimento não perde nada: o decodificador consegue deduzir quantos bytes leva o último grupo apenas pelo comprimento, e é por isso que esta ferramenta restaura o preenchimento quando você cola uma string sem ele.

Quebra de linha para PEM e MIME

Dois formatos exigem quebras de linha dentro da carga. O PEM, definido pelo RFC 7468, quebra a cada sessenta e quatro caracteres, e o OpenSSL recusa um certificado que chegue numa única linha longa. O MIME, definido pelo RFC 2045 seção 6.8, exige linhas de não mais de setenta e seis caracteres num corpo de mensagem, em parte porque os transportes antigos inseriam as suas próprias quebras e corrompiam a carga ao fazê-lo. Aqui, por padrão, não há quebra, porque os outros dois grandes consumidores de Base64 — um URI de dados e um campo JSON — precisam de uma única linha contínua, e uma quebra dentro de um URI de dados impede que ele carregue.

Codificar cada linha em separado

Às vezes o que você tem não é uma carga mas uma lista: uma coluna de valores, um conjunto de credenciais, um registro por linha. Codificar o bloco inteiro dá uma única string que tem de ser decodificada e novamente dividida. Codificar cada linha em separado dá um valor Base64 por linha, pronto para colar numa coluna. Os fins de linha do Windows estão contemplados: o retorno de carro é tratado como parte da quebra e não como o último caractere da linha, uma diferença que você só notaria mais tarde, como um caractere invisível no fim de cada valor decodificado.

Validação estrita

Quase todo o Base64 que chega a uma pessoa passou por alguma coisa: um cliente de chat que acrescentou aspas, um documento que transformou um hífen num travessão, um terminal que quebrou uma linha. A decodificação tolerante ignora o que não pertence ao alfabeto e restaura o preenchimento ausente, que é o que se quer na maioria das vezes. A validação estrita serve para quando você precisa saber que a carga é exatamente a que foi produzida: recusa caracteres desconhecidos, recusa preenchimento no meio e recusa um caractere final cujos bits restantes não sejam zero — a única falha que de outro modo é completamente invisível, porque esses bits são descartados de qualquer maneira.

Codificações de texto na saída

Decodificar dá bytes, e transformar bytes em texto legível é uma segunda decisão que a ferramenta tem de acertar. Leia uma carga Windows-1252 como UTF-8 e cada aspa curva vira um caractere de substituição; leia UTF-16 como UTF-8 e você obtém um NUL entre cada letra. São oferecidas sete codificações mais uma detecção automática que primeiro lê uma marca de ordem de bytes, depois testa os bytes contra as regras do UTF-8, depois procura o padrão denso e unilateral de NUL que só o UTF-16 produz, e só então recorre a Windows-1252 — que fica em último porque é a única das oito capaz de decodificar qualquer sequência de bytes, por isso tudo o que viesse depois nunca teria vez.

O Base64 permite passar cargas binárias por sistemas que só toleram texto simples, mantém a configuração portátil e combina bem com APIs e marcação que incorporam recursos pequenos. Codifique texto para Base64 ou decodifique-o, a partir de texto ou de arquivos, com conversão em tempo real enquanto você digita.

Para que serve o Base64

• Transporte: Mova bytes com segurança por e-mail, JSON, XML ou registros sem corromper os fins de linha.
• Incorporação: Insira imagens ou fontes minúsculas como URI de dados quando um arquivo à parte é inconveniente.
• Interoperabilidade: Compartilhe a mesma representação segura em ASCII entre Windows, macOS, Linux e a web.
• Armazenamento: Armazene blobs opacos em armazenamentos orientados a texto quando não há colunas binárias.
• Depuração: Inspecione respostas de API ou certificados como strings legíveis durante o desenvolvimento.
• Tokens: Leia o cabeçalho e a carga de um JSON Web Token, que são Base64 seguro para URL sem preenchimento.

Os seus bytes são divididos em grupos de seis bits; cada grupo corresponde a um caractere do alfabeto, e o preenchimento mantém o comprimento múltiplo de quatro caracteres.

O processo de codificação

• Entrada: O texto se torna bytes na codificação que você escolher; os arquivos já são bytes e são lidos diretamente.
• Agrupamento de bits: O fluxo de bytes é dividido para que cada índice selecione um de sessenta e quatro símbolos.
• Preenchimento: Os símbolos = finais marcam quando o último bloco precisou de bits de preenchimento.
• Formatação: O resultado fica numa linha, é quebrado em 64 ou 76 caracteres, ou é envolvido como URI de dados.
• Saída: Você obtém texto pronto para colar em código, num arquivo de configuração, numa folha de estilo ou numa requisição de API.
• Decodificação: Os passos são executados ao contrário para recuperar a sequência de bytes original, que depois é lida como texto ou devolvida como arquivo.

Um URI de dados transporta um arquivo inteiro dentro de uma única string, por isso uma imagem, um ícone ou uma fonte pequenos podem viver no HTML ou na folha de estilo que os usa em vez de numa requisição à parte. É a razão mais comum para alguém abrir um codificador Base64.

A forma de um URI de dados

A gramática é data:, depois um tipo de mídia opcional, depois parâmetros opcionais, depois uma vírgula, depois a carga. Quando a carga é Base64, a palavra base64 aparece mesmo antes da vírgula. O tipo de mídia importa mais do que parece: um URI de dados sem ele é tomado como texto simples, por isso um PNG escrito sem tipo aparece como imagem quebrada numa tag img e como nada em CSS. Esta ferramenta escreve sempre o tipo de mídia, deduzindo-o dos bytes de assinatura do próprio arquivo quando o arquivo não o declara.

Quando incorporar e quando não

Incorporar elimina uma requisição, o que compensa para algo minúsculo e necessário de imediato: um logotipo num modelo de e-mail, um ícone numa folha de estilo, um substituto num conjunto de testes. Logo deixa de compensar. O Base64 acrescenta cerca de um terço do tamanho, um recurso incorporado não pode ser armazenado em cache separadamente do documento que o transporta, e um URI de dados grande torna o próprio documento mais lento para processar. Como regra prática, incorpore o que se mede em kilobytes e hospede o que se mede em centenas de kilobytes.

Assim que uma string Base64 tem de viajar dentro de um URL, o alfabeto padrão se torna um problema, e a solução é uma variante que está na norma desde 2006.

Por que o mais e a barra falham num URL

Uma barra separa segmentos de caminho, por isso uma carga que contenha uma é lida como dois segmentos. Um mais é decodificado como espaço numa string de consulta por convenção antiga, por isso uma carga que contenha um volta alterada. Um sinal de igual separa um parâmetro do seu valor. Os três aparecem em saída Base64 comum, e é por isso que o RFC 4648 seção 5 define a variante segura para URL: hífen em vez de mais, sublinhado em vez de barra, e preenchimento que pode omitir.

Ler um JSON Web Token

Um JWT são três segmentos Base64 seguros para URL separados por pontos, sem preenchimento. Cole um segmento aqui e ele é decodificado sem mudar nenhuma configuração, porque o alfabeto é detectado a partir da string e o preenchimento ausente é restaurado. O cabeçalho e a carga são JSON legível. A assinatura não é para ser lida e virá como bytes — decodifique-a para um arquivo em vez de para texto, ou parecerá uma falha de decodificação quando não é nada disso. O Base64 não é criptografia e a carga de um JWT não é secreta: quem tiver o token pode lê-la exatamente como você acabou de fazer.

A maioria dos problemas reportados com Base64 não são problemas de Base64. São uma string que passou por alguma coisa pelo caminho, e o que uma ferramenta pode fazer de útil é dizer por qual coisa.

As falhas que vale a pena conhecer

Um comprimento que deixa um caractere a mais não pode ser Base64 de jeito nenhum — nenhuma sequência de bytes se codifica assim — por isso é quase sempre um caractere perdido ao copiar. Preenchimento no meio costuma significar que foram coladas duas cargas seguidas. Caracteres fora do alfabeto costumam ser pontuação introduzida por um cliente de chat ou um processador de texto, e o espaço inquebrável é o mais cruel porque é invisível. Uma mistura de mais-barra e hífen-sublinhado significa que um localizar e substituir passou por metade da string. Um caractere final cujos bits restantes não são zero significa que a string foi alterada depois de codificada, e é a única destas falhas sem sintoma visível, porque esses bits são descartados na decodificação de qualquer forma.

Hábitos que evitam tudo isto

Copie de uma visualização em texto simples e não de uma renderizada. Decida de uma vez se a sua API espera Base64 padrão ou seguro para URL e escreva-o onde quem a chama o veja. Quando uma carga tiver de sobreviver a um corpo de mensagem ou a um arquivo de certificado, quebre-a como esse formato exige em vez de esperar que nada quebre a linha sozinho. E quando algo der errado, veja primeiro o comprimento: é um teste de um segundo que exclui metade das hipóteses.

Conhecer a sobrecarga de tamanho e a diferença para a criptografia evita expectativas erradas em sistemas em produção.

Referência rápida

• Conte com um aumento de tamanho de cerca de trinta e três por cento em relação ao binário original da mesma carga.
• O alfabeto MIME usa A–Z, a–z, 0–9, mais + e /; as variantes seguras para URL trocam os símbolos mas seguem a mesma ideia.
• Os caracteres de preenchimento mantêm os decodificadores alinhados quando o número de bytes não é divisível por três.
• O Base64 é reversível e determinístico para os alfabetos padrão, e é por isso que nunca deve substituir a criptografia.
• Arquivos muito grandes se tornam strings muito longas; os navegadores podem parecer mais lentos simplesmente porque a string é enorme.
• Quatro caracteres Base64 transportam sempre exatamente três bytes, por isso pode calcular o tamanho decodificado antes de decodificar seja o que for.

Boas práticas

Use a ferramenta certa: Base64 para transporte e incorporação, criptografia para confidencialidade, compressão antes de codificar quando a largura de banda conta.

• Valide a saída decodificada num ambiente de testes antes de confiar em pipelines automatizados.
• Retire o espaço em branco de strings coladas se copiou de documentos formatados.
• Prefira hospedagem dedicada de recursos para mídia grande em vez de URI de dados gigantescos.
• Documente se a sua API espera Base64 padrão ou seguro para URL, para evitar erros subtis.
• Nunca armazene senhas ou segredos apenas atrás de Base64 — eles são decodificados num instante.
• Comprima antes de codificar, nunca depois: a saída Base64 é texto e comprime muito pior do que os bytes de onde veio.

Casos de uso comuns

• Desenvolvimento web: Experimente URI de dados ou simule respostas de API que levam amostras binárias.
• Automação: Prepare cargas para scripts que só aceitam entrada de texto.
• E-mail e MIME: Entenda anexos que historicamente eram codificados para caminhos SMTP de sete bits.
• Configuração: Serialize chaves curtas ou somas de verificação em arquivos do tipo .env.
• Ensino: Demonstre como as camadas de representação se apoiam sobre os bits brutos.
• Certificados: Leia um bloco PEM sem linha de comando — cole-o com as linhas BEGIN e END.

Os dois sentidos aceitam arquivos, o que é incomum: a maioria das ferramentas Base64 codifica um arquivo e depois obriga você a colar texto para voltar atrás.

Que arquivos cada sentido aceita

A codificação aceita tudo, porque o Base64 está definido sobre bytes arbitrários e não há arquivo que não consiga representar. A decodificação aceita arquivos cujo conteúdo seja texto Base64 — .txt, .b64, .pem, .crt, .key e as restantes extensões de texto simples — e recusa o resto no momento em que você o escolhe, com um link para trocar de sentido, em vez de aceitá-lo e falhar depois. Uma vez decodificados, os bytes são identificados pelos seus próprios números mágicos, por isso um PNG decodificado é devolvido como .png e um PDF decodificado como .pdf.

O que o plano gratuito inclui e o que o Pro acrescenta

O plano gratuito converte um arquivo por vez, até 25 MB. É uma decisão de plano e não um limite do dispositivo: aqui um arquivo de 25 MB é codificado em poucos centésimos de segundo, e o trabalho nunca toca na página que você está vendo. O Pro põe até cem arquivos em fila, os converte um após o outro e os devolve num único ZIP com os nomes repetidos tornados únicos — o que importa mais do que parece, porque dois arquivos chamados foto.png de pastas diferentes virariam uma só entrada e o arquivo conteria discretamente menos arquivos do que os que converteu.

O Base64 é uma representação, não uma compressão nem uma proteção. Aumenta os dados, qualquer pessoa o reverte trivialmente, e nunca deve ser a única coisa entre um segredo e quem ler o seu arquivo de configuração. Também não repara dados que já estavam errados antes de serem codificados.

Tudo roda no seu dispositivo. A conversão acontece fora da página, por isso digitar continua fluido por maior que seja a carga, e um arquivo de 25 MB é convertido em cerca de quinze milésimos de segundo num navegador de desktop atual. Nada é enviado, e a ferramenta continua funcionando com a rede desligada depois que a página carrega.

• Codificador Base64
• Decodificador Base64
• Codificador/decodificador de URL
• Todos os conversores
• Gerador de hash
• Gerador de UUID
• Formatador JSON
• Gerador de código QR
• Leitor de código QR
• Conversor de cores
• Comprimir uma imagem primeiro
• Gerador de favicon
• Escapar JSON
• Minificador JSON
• Aparador de texto
• Todas as ferramentas de texto