Decodificador de imagem Base64
Cole uma string Base64 para pré-visualizar e baixar a imagem.
Como usar
- Cole uma string de imagem codificada em Base64 na área de entrada. Ela pode incluir o prefixo
data:image/…ou não. - Clique em Decodificar imagem para pré-visualizá-la.
- Clique em Baixar imagem para salvá-la como arquivo PNG.
Perguntas frequentes
Quais formatos Base64 são suportados?
Você pode colar uma string Base64 bruta (a ferramenta detecta o formato automaticamente) ou uma URI de dados completa como data:image/png;base64,…
Há um limite de tamanho?
Não há limite rígido, mas strings Base64 muito grandes (mais de 5–10 MB) podem demorar para processar dependendo do seu dispositivo.
Como codificar uma imagem em Base64?
Use nossa ferramenta Conversor de imagem para Base64 · basta arrastar e soltar sua imagem para obter a string Base64.
O que o Base64 realmente é
O Base64 é um esquema de codificação de binário para texto definido na RFC 4648 (outubro de 2006). Ele usa um alfabeto de 64 caracteres, A-Z, a-z, 0-9, mais + e /, para representar bytes arbitrários como ASCII imprimível. Cada três bytes de entrada binária viram exatamente quatro caracteres de saída, porque o mínimo múltiplo comum de 6 bits (um caractere Base64) e 8 bits (um byte) é 24. Essa proporção de quatro para três também é o motivo de um arquivo codificado em Base64 ser cerca de 33% maior do que o binário original.
Quando o comprimento da entrada não é um múltiplo de três, o Base64 preenche com = para que a saída seja sempre um múltiplo de quatro caracteres: um byte final produz dois caracteres mais ==; dois bytes finais produzem três caracteres mais =. Alguns codificadores removem o preenchimento, então um decodificador robusto precisa re-preencher antes de passar a string para atob().
A RFC 4648 também define uma variante segura para URL (às vezes chamada de base64url) que troca + por - e / por _. Os JWTs a usam. Este decodificador normaliza ambos os alfabetos, então você não precisa pensar em qual deles recebeu.
O esquema de URI de dados
A RFC 2397 (agosto de 1998) define o esquema de URL data:. A gramática completa é:
data:[<mediatype>][;base64],<data>Um PNG embutido típico se parece com data:image/png;base64,iVBORw0KGgo…. O token ;base64 é um marcador (note a ausência de um sinal de =) que diz ao navegador para decodificar a carga a partir de Base64 em vez de tratá-la como texto codificado em percentual. Se você omitir ;base64, os dados são interpretados como texto codificado em URL. Se você omitir o tipo de mídia inteiramente, a spec usa text/plain;charset=US-ASCII por padrão.
Este decodificador aceita qualquer uma das formas: cole uma URI de dados completa ou apenas a carga Base64. Quando só a carga é fornecida, o formato é detectado a partir dos primeiros bytes decodificados, veja abaixo.
Como o formato é detectado
Se você colar uma string Base64 bruta sem o prefixo data:image/…, a única forma de saber que tipo de imagem é olhar os primeiros bytes decodificados, todo formato de imagem comum começa com uma assinatura reconhecível, formalmente chamada de «número mágico». Os navegadores fazem exatamente a mesma verificação ao farejar tipos MIME (o procedimento está no padrão MIME Sniffing da WHATWG). O atalho é que essas assinaturas se traduzem em prefixos Base64 previsíveis:
| Formato | Primeiros bytes (hex) | Prefixo Base64 |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF89a | 47 49 46 38 39 61 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 42 50 | UklGR |
| BMP | 42 4D («BM») | Qk |
| SVG (texto XML) | começa com <?xml ou <svg | PD94bWwg ou PHN2Zw |
A assinatura do PNG é uma das mais engenhosas do zoológico de formatos. O byte 89 tem o bit mais alto definido, então um relay de e-mail de apenas 7 bits o corrompe de forma visível. Os três bytes seguintes soletram PNG em ASCII, para que um humano rodando head no arquivo consiga reconhecê-lo. Depois vêm um final de linha do DOS (0D 0A), um Ctrl-Z do MS-DOS que impede o comando legado TYPE de continuar imprimindo, e um avanço de linha do Unix (0A): entre eles, detectam todo transporte comum que «prestativamente» reescreve os finais de linha.
De onde vêm as imagens Base64
A maioria das pessoas que chega a uma ferramenta como esta está depurando alguma coisa. Situações comuns:
- Respostas de API em JSON. O JSON não tem um tipo binário nativo, então as APIs entregam imagens, PDFs assinados, fotos de perfil e capturas de tela enviadas como strings Base64 dentro de campos JSON. Colar o valor aqui deixa você ver o que ele realmente era.
- CSS e ativos empacotados. O Webpack e o Vite têm um limite de ativo pequeno (o Vite usa 4 KB por padrão) que embute automaticamente imagens pequenas como URIs de dados no CSS ou JS empacotado. Ao depurar «de onde vem este ícone?», a URI de dados vai parar aqui.
- Assinaturas de e-mail em HTML. O Gmail, o Outlook e o Apple Mail embutem as imagens de assinatura como URIs de dados para que a imagem sobreviva ao encaminhamento. Às vezes, os designers precisam recuperar o logo original.
- Exportações de CMS e do Notion. Exportações XML do WordPress, exportações do Notion e backups do Confluence embutem as miniaturas como Base64 para manter a exportação autocontida.
- QR codes e blocos de assinatura. As bibliotecas de navegador que geram QR codes (qrcode.js) ou capturam assinaturas manuscritas (signature_pad) normalmente expõem a sua saída como uma string
data:image/png;base64,…. - Geração de PDF do lado do servidor. Ferramentas como Puppeteer, openhtmltopdf e iText aceitam HTML com URIs de dados embutidas. Quando um logo «não aparece» no PDF renderizado, decodificar a URI é a forma mais rápida de ver se os bytes eram sequer uma imagem.
Você deve embutir imagens como Base64?
A troca costumava ser mais interessante. No HTTP/1.1, cada imagem era uma requisição bloqueante separada e embutir um ícone minúsculo podia economizar uma ida e volta real. No HTTP/2 e no HTTP/3, o caso se estreitou drasticamente. Resumo honesto:
Você ganha: zero requisições HTTP extras, entrega atômica e artefatos autocontidos que funcionam sem dependências externas (demos de arquivo único, e-mail, PDFs renderizados no servidor).
Você perde: o navegador não consegue armazenar em cache uma URI de dados embutida separadamente, então a mesma imagem em dez páginas é baixada novamente a cada resposta HTML. O ativo codificado é cerca de 33% maior do que o equivalente binário. As CDNs não conseguem desduplicar imagens embutidas em várias páginas. Os pipelines de otimização de imagem (Cloudinary, Vercel, <Image> do Next.js) não conseguem inspecionar, comprimir, redimensionar ou servir formatos modernos como AVIF ou WebP para ativos embutidos. O navegador também precisa decodificar primeiro o Base64 e depois a imagem, o que é CPU extra a cada renderização.
Regras práticas razoáveis: embuta imagens menores do que cerca de 4 KB usadas em apenas um lugar, placeholders de um único pixel e imagens que precisam viajar dentro de um arquivo autocontido. Não embuta nada usado em mais de uma página, nada maior do que cerca de 4 KB, nada que deva ser carregado de forma preguiçosa, nem nada que se beneficie da negociação de formato.
Segurança: o que o Base64 não faz
O Base64 é codificação, não criptografia. A RFC 4648 §12 avisa explicitamente que ele «esconde visualmente» os dados, mas não fornece «nenhuma confidencialidade computacional», qualquer um pode decodificá-lo instantaneamente. Não codifique senhas ou chaves de API em Base64 achando que é uma medida de segurança.
Dois detalhes de segurança que vale conhecer:
- A navegação de nível superior para URLs
data:é bloqueada nos navegadores modernos (abrir uma em uma nova aba não funciona) para mitigar ataques de phishing que renderizavam páginas de login falsas a partir de URIs de dados. O uso como sub-recurso (<img src="data:…">,url(data:…)no CSS) ainda é permitido. - O SVG é especial. O SVG é XML e os documentos SVG podem conter elementos
<script>e manipuladores de eventos. Carregar um SVG em uma tag<img>é seguro (os navegadores rodam um renderizador com scripts desabilitados), mas carregar o mesmo SVG em um<object>ou<iframe>pode executar JavaScript arbitrário. Este decodificador só define<img src>, que é o caminho seguro. Se você decodificou um SVG de uma fonte não confiável, trate o arquivo como qualquer outro documento não confiável.
Mais perguntas
Por que a minha string Base64 falha com «InvalidCharacterError»?
Três causas comuns: espaço em branco ou quebras de linha perdidas de um copiar-e-colar (o perfil MIME Base64 mais antigo quebra as linhas a cada 76 caracteres, o que o atob() do JavaScript rejeita); Base64 segura para URL com - e _ em vez de + e /; ou preenchimento = final removido, de modo que o comprimento não é um múltiplo de quatro. Este decodificador limpa o espaço em branco, normaliza o alfabeto e re-preenche antes de decodificar, mas strings muito corrompidas ainda falham.
Eu perco qualidade ao decodificar?
Não. A decodificação é o inverso exato da codificação, você recupera a imagem original byte a byte. O download está no formato que estava no Base64 (PNG, JPEG, WebP, GIF, BMP ou SVG), sem nenhuma etapa de recodificação.
Qual é a maior URI de dados que um navegador aceita?
Segundo o MDN, os limites atuais são de cerca de 512 MB para o Chromium e o Firefox, e de cerca de 2 GB para o Safari/WebKit. Na prática, o gargalo é a memória e a CPU, e não a spec de URL: colagens acima de aproximadamente 10 MB começam a parecer lentas em um laptop comum.
Algo é enviado a um servidor?
Não. A decodificação acontece inteiramente no seu navegador via a função nativa atob() e um Blob ou uma URI de dados atribuída a uma tag <img>. Nada é enviado; a página funciona offline depois de carregada.
Por que o Base64 de todo JPEG começa com /9j/?
Quase todo arquivo JPEG por aí começa com os bytes FF D8 FF (marcador de Início de Imagem seguido de outro byte marcador). Quando você codifica em Base64 três bytes que são todos FF com um D8 no meio, o padrão de bits 11111111 11011000 11111111 se divide em grupos de 6 bits 111111 111101 100011 111111: as posições 63, 61, 35, 63 do alfabeto Base64, que soletram /9j/. O quarto caractere então varia dependendo de qual marcador vem em seguida (E0 para JFIF, E1 para Exif), mas os três primeiros são universais.