Ferramenta de Conversão de Imagem Base64

A ferramenta de imagem em Base64 converte arquivos de imagem em texto Base64 ou data URLs, e também decodifica essas strings para exibir a imagem novamente. Ela é útil para ícones pequenos, placeholders, modelos de e-mail, fundos CSS, testes de API e demonstrações em que enviar um arquivo separado seria incômodo. Base64 não é compressão: normalmente aumenta o tamanho dos dados e pode prejudicar o cache em fotos grandes ou recursos repetidos. Use a conversão para inspecionar e depurar antes de escolher entre dados incorporados, CDN ou uma URL de imagem comum.

Uma imagem codificada em Base64 é um data URI conforme definido na RFC 2397: o prefixo de esquema data:, o tipo MIME como image/png, o literal ;base64 e depois o payload construído com o alfabeto de 64 caracteres A-Z, a-z, 0-9, +, /, com = como preenchimento terminal. A codificação pega o fluxo binário de três bytes de cada vez e emite quatro caracteres, de modo que o payload cresce por um fator fixo de 4/3 (aproximadamente 33%) mais um ou dois caracteres de preenchimento quando o número de bytes não é múltiplo de três.

No navegador, a codificação começa com FileReader.readAsDataURL, que processa o arquivo pelo mesmo pipeline e retorna a URL data: completa, pronta para ser usada em um <img src> ou em um url() de background-image no CSS. As primitivas btoa e atob, que trabalham apenas com strings, operam em payloads já binários (apenas latin-1, portanto bytes binários precisam ser convertidos via Uint8Array). A decodificação de volta para uma imagem visualizável passa por atob para um Uint8Array, depois para um Blob com o tipo MIME original, e o handle URL.createObjectURL se torna um recurso HTTP normal e recuperável.

O trade-off prático não é largura de banda, mas cache. Cada ocorrência do payload é duplicada onde quer que o HTML, CSS ou JSON apareça, então o recurso não pode ser cacheado separadamente, não pode ter seu próprio ETag e é rebaixado a cada documento pai. Regras estritas de Content-Security-Policy também bloqueiam data: URIs, a menos que 'data:' esteja explicitamente listado em img-src ou style-src. Desde que a multiplexação HTTP/2 foi implementada, incorporar ícones pequenos raramente supera uma requisição separada, então a regra moderna é incorporar apenas abaixo de ~2 KB e manter imagens principais e sprites reutilizáveis como arquivos cacheáveis.

• Esquema Data URI: formato RFC 2397 data:[<mime>][;base64],<payload>; a vírgula é obrigatória e é a falha de cópia mais comum.
• Sobrecarga de codificação: 3 bytes binários se tornam 4 caracteres ASCII, então o payload cresce por um fator de 4/3 (~33%) mais até 2 caracteres de preenchimento '='.
• APIs do navegador: FileReader.readAsDataURL para arquivos; btoa/atob para payloads já em texto (apenas latin-1, portanto binário precisa de uma ponte Uint8Array).
• Caminho de decodificação: atob → Uint8Array → new Blob([buf], {type}) → URL.createObjectURL fornece uma URL de recurso recuperável normal em vez de uma string congelada.
• Problema com CSP: uma política img-src ou default-src estrita bloqueia data: a menos que a palavra-chave esteja explicitamente listada, o que silenciosamente quebra imagens incorporadas em produção.
• Trade-off de cache: dados incorporados não têm ETag ou entrada de cache independente, então a multiplexação HTTP/2 geralmente supera a incorporação para qualquer coisa acima de ~2 KB.