Imagem para Base64 — gerador de data URI
Solte uma imagem e receba um data URI para colar em uma folha de estilos, em um atributo HTML ou em um arquivo Markdown. A codificação acontece no seu navegador, então a imagem nunca é enviada — e isso importa, porque um data URI é o arquivo inteiro escrito em texto puro.
Arraste uma imagem aqui ou escolha um arquivo
PNG, JPG, SVG, GIF, WebP, ICO · uma por vez · nada é enviado
Prévia
O texto completo, pronto para colar em um atributo src.
Converter um data URI de volta em imagem
O que um data URI é de verdade
Um data URI é um arquivo inteiro escrito como uma URL. O formato é fixo: o esquema data:, depois o tipo de mídia, depois opcionalmente ;base64, depois uma vírgula e depois o conteúdo. Então data:image/png;base64,iVBORw0KGgo… diz "o que vem a seguir é um PNG, codificado em Base64". Nada é baixado de lugar nenhum; os bytes já estão ali.
O Base64 existe porque uma URL não pode conter bytes arbitrários. Ele mapeia cada três bytes em quatro caracteres de um alfabeto de 64 caracteres que sobrevive a ser colado dentro de um texto. Quatro caracteres para cada três bytes é de onde vem o acréscimo de 33%, e não há como evitá-lo: é aritmética, não um detalhe de implementação. O preenchimento com = no fim arredonda a entrada para um múltiplo de três.
Vale dizer com todas as letras: Base64 não é compressão e não é criptografia. Ele deixa o arquivo maior e qualquer pessoa consegue ler de volta. As estatísticas acima mostram o custo real.
Quando embutir vale a pena
O argumento a favor de um data URI é que ele elimina uma requisição de rede. Esse argumento era muito mais forte antes do HTTP/2, quando os navegadores abriam um punhado de conexões por host e cada arquivo extra ficava na fila atrás dos outros. Hoje a multiplexação barateia as requisições pequenas, e os motivos para embutir se reduziram a poucas situações:
- Recursos minúsculos —ícones, padrões, um degradê de 1 px— abaixo de um ou dois kilobytes, mais ou menos.
- Algo que precisa existir mesmo que o resto do site esteja fora do ar, como uma página offline.
- Um único arquivo que você precisa entregar a alguém sem hospedagem nenhuma: um modelo de e-mail em HTML que você vai colar em outro lugar, um bookmarklet, um relatório autocontido.
O argumento contra é o cache. Uma imagem referenciada por URL é guardada em cache uma única vez e reaproveitada em todo lugar. A mesma imagem embutida em uma folha de estilos é baixada de novo toda vez que essa folha muda, não pode ser carregada sob demanda, não pode ser servida em outro formato para os navegadores que o suportam e fica no caminho crítico bloqueando a primeira renderização. Embuta uma foto de 200 KB no seu CSS e você acabou de deixar toda página do site 270 KB mais lenta para começar a renderizar.
SVG nunca deveria ir em Base64
SVG já é texto. Codificar em Base64 acrescenta um terço ao tamanho sem benefício nenhum e deixa o arquivo ilegível. Codificar em porcentagem os poucos caracteres que quebrariam um url() do CSS mantém tudo curto, mantém tudo legível e comprime muito melhor na transmissão, porque o gzip encontra repetição em XML e não encontra nenhuma em Base64. Esta ferramenta faz isso automaticamente quando você entrega um SVG.
Coisas que vão te complicar a vida
- Clientes de e-mail. O Gmail e vários outros se recusam a exibir uma imagem vinda de um data URI. Se o destino é um e-mail, hospede a imagem e aponte para ela.
- Content Security Policy. Uma política
img-src 'self'bloqueia data URIs. A diretiva precisa dedata:adicionado explicitamente, e alguns times não vão permitir isso. - Você não consegue abrir um na barra de endereços. Os navegadores bloqueiam há anos a navegação de nível superior para URLs
data:, porque era um golpe de phishing fácil. Use o painel do decodificador aqui em cima. - O suporte em Markdown é irregular. Funciona em muitos renderizadores e é removido nos comentários do GitHub.
- Textos longos são lentos de editar. Um megabyte de Base64 em uma caixa de texto vai deixar o seu editor, e esta página, pesados. Isso é uma dica do que ele vai fazer com o seu build.
O decodificador é propositalmente tolerante: se você colar um conteúdo sem o prefixo data:, ele olha os primeiros caracteres e adivinha o formato a partir deles, porque os bytes iniciais de PNG, JPEG, GIF e WebP são distintos o bastante para sobreviver à codificação Base64. Um conteúdo que um cliente de e-mail quebrou em várias linhas ainda funciona; um que foi truncado vai decodificar e depois falhar ao ser exibido.
Perguntas frequentes
Por que a versão em Base64 é maior que o arquivo original?
Porque o Base64 gasta quatro caracteres a cada três bytes, o que dá um aumento fixo de 33%, mais alguns caracteres de prefixo. É uma codificação, não um formato de compressão. Se você precisa do arquivo menor, comprima a imagem antes de codificar.
Devo embutir imagens como data URI?
Só as pequenas. Abaixo de um ou dois kilobytes, a requisição economizada compensa. Acima disso, perder o cache separado, o carregamento sob demanda e a negociação de formato custa mais do que aquela requisição jamais custou, ainda mais com HTTP/2.
Posso usar um data URI em um e-mail?
Normalmente não. O Gmail e vários outros clientes bloqueiam data URIs em tags de imagem, então quem recebe vê uma imagem quebrada. Hospede o arquivo em algum lugar e use uma URL normal, por mais inconveniente que isso seja.
Qual é o tamanho máximo de um data URI?
Nos navegadores atuais não há limite para uma imagem em um src ou em um url() do CSS. O limite prático é a sua paciência: textos muito longos deixam lentos o parsing, a edição e cada etapa do build que toca o arquivo.
Minha imagem é enviada quando eu codifico?
Não. O arquivo é lido com a API FileReader do navegador e codificado localmente. Ele nunca sai do seu dispositivo, o que aqui importa mais que o normal, porque um data URI é uma cópia completa do arquivo em texto puro.
Última atualização 19 de setembro de 2026