Conversor de imagem para Base64

Como funciona

1. Arraste ou escolha uma imagem. O navegador lê o arquivo localmente com a API FileReader. Nada é enviado a lugar nenhum.
2. O codificador converte os bytes usando o alfabeto Base64 padrão: a cada 3 bytes de entrada correspondem 4 caracteres ASCII tirados de A-Z a-z 0-9 + /, com até dois caracteres de preenchimento = ao final quando o comprimento da entrada não é múltiplo de 3.
3. Copie o que você precisa. «Copiar o Base64» dá apenas a string codificada (útil para payloads JSON ou processamento no backend). «Copiar o URI de dados» dá a forma completa data:image/png;base64,…, pronta para colocar em um atributo <img src> ou em um background-image: url(…) no CSS.
4. Cole onde for preciso. A saída é texto simples: funciona em HTML, CSS, JSON, JavaScript, Markdown ou em qualquer outro lugar em que uma string possa existir.

O que o Base64 realmente faz

O Base64 é definido na RFC 4648 (outubro de 2006). A codificação processa 24 bits de entrada por vez (três bytes) e os reescreve como quatro índices de 6 bits em um alfabeto de 64 caracteres. A matemática é exata: 3 bytes (24 bits) → 4 caracteres (cada um carregando 6 bits). Quando o comprimento da entrada não é múltiplo de 3, o codificador acrescenta caracteres de preenchimento = para tornar o comprimento da saída um múltiplo de 4.

Duas consequências práticas:

• A saída é sempre ~33% maior que a entrada. A proporção de 4/3 é fundamental para o algoritmo. Uma imagem de 100 KB vira ~133 KB em Base64. Com quebras de linha de 76 caracteres no estilo MIME, o acréscimo fica mais perto de 37%.
• A saída é segura como texto em qualquer lugar. O alfabeto de 64 caracteres é a interseção de todo canal de texto ASCII comum: HTML, JSON, XML, e-mail, URLs (com a variante segura para URL), código-fonte. Essa é toda a razão de o Base64 existir: mover dados binários por sistemas que foram projetados para texto.

A RFC 4648 §12 deixa explícita uma não funcionalidade importante: «a codificação Base64 oculta visualmente informações que de outra forma seriam facilmente reconhecíveis, como senhas, mas não oferece nenhuma confidencialidade computacional.» Qualquer um consegue decodificar uma string Base64 em duas linhas de código em qualquer linguagem. É codificação, não criptografia.

URIs de dados: a forma de imagem incorporada

Um «URI de dados» é o formato de invólucro que permite a uma string Base64 tomar o lugar da URL de uma imagem. A RFC 2397 (1998) define a sintaxe:

data:[<mediatype>][;base64],<data>

Para imagens, isso significa data:image/png;base64,iVBORw0KGgo… em um atributo <img src> ou background-image: url("data:image/svg+xml;utf8,<svg…>") no CSS. O token ;base64 informa ao navegador que a parte dos dados está codificada; sem ele, os dados são tomados como texto com codificação percentual. A própria RFC 2397 observa que os URIs de dados são «úteis apenas para valores curtos», uma dica que envelheceu e virou uma regra rígida de desempenho.

Quando você deve incorporar uma imagem como Base64

• Artefatos de arquivo único. Uma assinatura de e-mail com um logotipo incorporado que precisa sobreviver ao encaminhamento. Uma demonstração HTML autocontida para o CodePen, o JSFiddle ou uma reprodução de relatório de bug. Um PDF gerado em que a imagem precisa estar incorporada para que o arquivo funcione offline.
• Ícones minúsculos no caminho crítico. Um chevron de 200 bytes ou um spinner de carregamento incorporado ao CSS crítico pode carregar mais rápido do que disparar uma requisição HTTP separada, especialmente em conexões lentas.
• Respostas JSON / de API em linha. Envios de avatar, assinaturas, amostras de OCR, QR codes gerados, qualquer coisa em que o consumidor da API espera os bytes embutidos em vez de uma URL separada para buscar.
• Iframes em sandbox ou outros contextos que proíbem o carregamento de recursos externos.
• Arquivos de configuração em que você não quer um arquivo de imagem ao lado do JSON / TOML / YAML.

Quando você não deve incorporar uma imagem como Base64

Para a maioria dos sites em produção, uma imagem Base64 incorporada é mais lenta que uma referência <img> normal. Cinco razões que se somam:

1. 33% de acréscimo de tamanho, sempre. Cada byte custa 4/3 de byte após a codificação. Quando o gzip é aplicado, o acréscimo aparente diminui (porque o Base64 é repetitivo), mas os bytes que o navegador analisa ainda são 33% maiores que o original.
2. A imagem não pode ser armazenada em cache separadamente. Um image.png externo é buscado uma vez e reutilizado em todas as páginas que se vinculam a ele. Uma imagem Base64 vive dentro do HTML ou do CSS e é baixada de novo a cada mudança nesse arquivo.
3. Deixa a análise de HTML e CSS mais lenta. Strings longas incorporadas dentro de um CSS que bloqueia a renderização empurram o caminho crítico para mais longe. Harry Roberts (CSS Wizardry) mediu a folha de estilos real de um cliente em 925 KB com imagens Base64 contra 708 KB sem elas, e 232 KB com gzip contra 68 KB. Remover o Base64 reduziu o CSS com gzip em 70,68%.
4. Não pode ter carregamento adiado. O atributo loading="lazy" adia a busca de uma imagem até que o usuário role para perto dela. As imagens Base64 já estão no documento: não há nada para adiar.
5. O HTTP/2 e o HTTP/3 já resolveram o problema do «excesso de requisições». A multiplexação permite que uma única conexão entregue centenas de arquivos em paralelo, então a justificativa original para a incorporação praticamente desapareceu.

Uma regra prática do PageSpeed do Google e da maioria dos especialistas em desempenho: incorpore apenas se a imagem tiver menos de ~1-2 KB codificada, e apenas se ela aparecer acima da dobra no CSS crítico. Qualquer coisa maior quase com certeza tem melhor desempenho como um arquivo separado.

SVG: use a codificação UTF-8, não o Base64

O SVG já é texto, então codificá-lo como Base64 desperdiça ~33% dos bytes sem nenhum benefício. A forma menor é o UTF-8 codificado em URL:

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

A maioria das ferramentas de build modernas (o postcss-inline-svg do PostCSS, o svg-url-loader do Webpack) emite a forma codificada em URL por padrão. Para SVG em linha, prefira essa forma ao Base64, a menos que um consumidor específico exija ;base64.

Tipos MIME que esta ferramenta reconhece

O prefixo de tipo de mídia do URI de dados é o que diz ao consumidor como interpretar os bytes. O navegador o detecta a partir do arquivo que você escolhe:

Notas de privacidade e segurança

A maioria dos sites de «imagem para Base64» online envia seu arquivo para o servidor deles, codifica lá e devolve o resultado. Isso significa que capturas de tela de interfaces ainda não lançadas, designs sob NDA, fotos de crianças, exames médicos ou assinaturas em contratos atravessam a infraestrutura de um terceiro. Esta ferramenta codifica localmente: o FileReader do navegador lê o arquivo na memória, o codificador roda em JavaScript no seu dispositivo, e a única coisa que sai da página é a string codificada quando você a copia.

Duas notas sobre Content Security Policy que vale a pena saber se você publica imagens Base64 em produção:

• As imagens Base64 incorporadas contornam as regras de img-src, a menos que você as permita explicitamente. Uma CSP rígida como img-src 'self' bloqueia os URIs data:. Para permiti-los, escreva img-src 'self' data:.
• O mesmo vale para as imagens de fundo incorporadas no CSS. Se uma CSP está bloqueando seus fundos incorporados, verifique primeiro a diretiva img-src.

Erros comuns

1. Tratar o Base64 como ofuscação. Não é. Qualquer um consegue decodificá-lo em duas linhas de qualquer linguagem. Não coloque credenciais, chaves de API ou dados sensíveis dentro de strings Base64 «para escondê-los».
2. Incorporar uma imagem de destaque de 200 KB. A imagem vira 266 KB codificada, fica presa dentro do HTML, não pode ser armazenada em cache separadamente, não pode ter carregamento adiado, e a primeira pintura da página fica visivelmente mais lenta. Sirva-a como um arquivo normal.
3. Copiar o Base64 cru quando você precisava do URI de dados. Uma string Base64 sozinha em um atributo <img src> renderiza como quebrada: você precisa do prefixo data:image/png;base64,. Use o botão «Copiar o URI de dados».
4. Codificar SVG em Base64. O SVG já é texto. Em vez disso, codifique-o em URL e economize os 33% de acréscimo.
5. Esquecer a CSP. Um img-src 'self' rígido bloqueia os URIs de dados. Acrescente data: à diretiva se você publica imagens Base64.
6. Tentar decodificar uma string Base64 com um prefixo data: no início. A parte data:image/...;base64, é metadado; remova-a antes de passar a string para um decodificador Base64.
7. Colar imagens confidenciais em um codificador do lado do servidor. Se a URL diz «codificar», mas a aba Network mostra um POST, sua imagem acabou de sair da sua máquina.

Perguntas frequentes

Qual é a diferença entre «Base64» e «URI de dados»?

O Base64 é a codificação (uma string como iVBORw0KGgo…). Um URI de dados é o invólucro que transforma uma string Base64 em algo que pode substituir a URL de uma imagem: data:image/png;base64,iVBORw0KGgo…. O invólucro informa ao navegador o tipo de mídia e a codificação, para que ele saiba como interpretar os bytes. Os dois botões desta ferramenta dão a você cada forma separadamente.

O Base64 é seguro?

Não, e não é para isso que ele serve. O Base64 é codificação, não criptografia. A RFC 4648 §12 coloca de forma direta: ele «não oferece nenhuma confidencialidade computacional.» Qualquer um consegue decodificar uma string Base64 instantaneamente. Se você precisa de privacidade, criptografe os dados primeiro (com AES etc.) e depois aplique o Base64 ao texto cifrado para o transporte.

Qual o tamanho máximo da imagem?

Não há limite rígido imposto pela ferramenta, já que a codificação acontece na memória do seu navegador. O teto prático é o que o seu dispositivo conseguir comportar: tipicamente, dezenas de MB funcionam bem em notebooks modernos. A restrição maior é o suporte do consumidor: muitos clientes de e-mail, navegadores e APIs têm seus próprios limites de tamanho de URI de dados, e incorporar qualquer coisa acima de alguns KB raramente faz sentido em termos de desempenho.

Por que minha string Base64 é 33% maior que o arquivo?

Porque cada caractere Base64 carrega 6 bits, enquanto cada byte de entrada carrega 8 bits. A menor unidade que o Base64 consegue representar sem resto é 3 bytes (24 bits = quatro caracteres de 6 bits), então a proporção de saída é exatamente 4/3 ≈ 1,33. Não há variante de Base64 que evite isso: está matematicamente embutido na codificação.

A imagem codificada vai funcionar em e-mail HTML?

Na maioria das vezes, mas nem sempre. O Apple Mail, o Gmail moderno e a maioria dos clientes de webmail renderizam as imagens data: de forma limpa. O Microsoft Outlook para desktop historicamente teve suporte inconsistente: algumas versões renderizam os URIs de dados bem, outras os removem por completo. Teste na sua lista de clientes-alvo antes de depender de imagens Base64 em e-mails transacionais. Para ampla compatibilidade, as URLs de imagens hospedadas ainda são a aposta mais segura.

Devo usar base64url (com - e _) no lugar?

Só se você estiver colocando os dados codificados em uma URL ou nome de arquivo em que + e / precisariam, de outra forma, de codificação percentual. Para atributos <img src> de HTML e valores background-image de CSS, o alfabeto padrão funciona. A RFC 4648 §5 define a variante segura para URL explicitamente para esses casos de URL/nome de arquivo, e adverte que ela «não deve ser chamada apenas de 'base64'» para evitar confusão com o alfabeto padrão.

Ferramentas relacionadas