Vale a pena usar imagens em Base64? Em geral, só as minúsculas

Para qualquer coisa maior que um ícone, não. Embutir uma imagem como data URI em Base64 economiza uma requisição de rede e custa 33% mais bytes, o cache próprio, o lazy loading e a negociação de formato. Abaixo de mais ou menos um kilobyte essa troca é justa: um ícone de marcador, um padrão de fundo, um spinner. Acima de alguns kilobytes, a requisição que você evitou era muito mais barata do que tudo o que você entregou em troca.

Quanto o Base64 aumenta o tamanho de uma imagem?

Um terço maior, por aí. O Base64 gasta quatro caracteres a cada três bytes, então o aumento é fixo em 33%, mais o prefixo data:image/png;base64, e até dois caracteres = de padding. Um PNG de 12 KB vira cerca de 16 KB de texto. Isso é aritmética, não uma fraqueza de algum encoder, e nenhuma ferramenta vai ficar abaixo disso. O que é Base64 de verdade tem a versão em nível de bits, se você quiser.

A compressão em trânsito devolve uma parte. Gzip e Brotli encontram alguma redundância em uma string Base64, então o tamanho transferido não chega aos 133% inteiros. Mas também nunca volta ao original, e em um PNG, JPEG ou WebP os bytes originais já vinham comprimidos, ou seja, não sobrava muito para espremer desde o começo. Conte com esse custo extra em vez de supor que a codificação de transferência o apaga.

O que você perde ao embutir uma imagem?

Uma imagem com URL própria é baixada uma vez e reaproveitada em todo lugar. Dê a ela um nome de arquivo com hash e um header de cache longo e o visitante que volta nunca mais a baixa, em página nenhuma.

A mesma imagem embutida em uma folha de estilos passa a fazer parte dessa folha de estilos. Mude uma cor que não tem nada a ver, publique um hash novo, e cada visitante baixa a imagem de novo junto. Se em vez disso você embutir no HTML, ela é baixada a cada visualização de página, porque o HTML normalmente não é cacheado de jeito nenhum.

O resto vai junto:

• Nada de lazy loading. loading="lazy" não faz nada por bytes que já estão no documento. Uma imagem embutida que fica fora da primeira tela é paga por inteiro, na hora.
• Nada de negociação de formato. Um elemento <picture> serve AVIF ou WebP aos navegadores que têm suporte a eles e algo mais antigo para o resto. Um data URI é uma única codificação fixa para todo mundo.
• Nada de tamanhos responsivos. srcset é uma lista separada por vírgulas e um data URI contém uma vírgula, então os dois não se misturam. O celular baixa o que o desktop precisava.
• Bloqueia a primeira pintura. Um data URI dentro do CSS é parseado antes de qualquer coisa ser renderizada. Uma foto de 200 KB embutida em uma folha de estilos atrasa o primeiro pixel em toda página que carrega essa folha de estilos.
• Destrói seus diffs. Uma linha de vinte mil caracteres muda toda vez que a imagem muda, e ninguém revisa essa linha.

Embutir ainda economiza tempo em HTTP/2?

Bem menos do que antes. O argumento clássico era a quantidade de requisições: no HTTP/1.1 o navegador mantinha cerca de seis conexões abertas por host e todo o resto ficava na fila, e é por isso que sprite sheets e data URIs eram o conselho padrão. O HTTP/2, padronizado em 2015 e com suporte em todos os navegadores atuais, multiplexa muitas requisições em uma única conexão. Um arquivo pequeno a mais não é de graça — ele ainda carrega seus próprios headers e trabalho no servidor — mas não bloqueia mais nada.

O que sobrevive é a latência no primeiríssimo carregamento. Uma requisição ainda precisa de uma ida e volta, e numa conexão móvel lenta isso é mensurável. É por isso que o único uso honesto que resta para embutir são assets minúsculos necessários na primeira pintura: não fotografias, não imagens de capa, nada que você chamaria de conteúdo.

Quando embutir ainda é a escolha certa?

• Assets com menos de um ou dois kilobytes que aparecem na maioria das páginas: um chevron, a marca de um checkbox, um fundo que se repete, um spinner de carregamento.
• Um arquivo que precisa funcionar sem hospedagem nenhuma. Um relatório HTML de arquivo único que você manda anexado por e-mail, um bookmarklet, uma demo autocontida que alguém vai abrir da área de trabalho. Não há servidor de onde buscar uma imagem, então a imagem precisa estar dentro do arquivo.
• Uma página offline. O que quer que seu service worker mostre quando a rede cai não pode depender de um fetch.
• Qualquer lugar onde binário não é permitido. JSON não tem tipo binário, então uma imagem que viaja dentro do payload de uma API ou de um arquivo de configuração tem que ser Base64. O custo é que o arquivo vira uma única linha enorme e ilegível.

Repare no que não está nessa lista: fotografias, logos de mais de um ou dois kilobytes, qualquer coisa que apareça em uma única página e qualquer coisa que um usuário envie.

Que tamanho é grande demais para embutir?

Codifique o arquivo e olhe o comprimento da string. Essa é a decisão inteira. Jogar a imagem no conversor para data URI deste site coloca lado a lado os bytes originais, os bytes codificados e o custo extra: o número codificado conta a string inteira, prefixo incluído, então fica um pouco acima de 33% em vez de exatamente nisso. Ele avisa sem rodeios assim que a string passa de 100 KB, mas trate isso como o ponto em que embutir é indefensável, não o ponto em que deixa de ser sensato. A tabela é o julgamento que a ferramenta não faz por você. Nada é enviado, o que aqui importa mais que de costume: um data URI é uma cópia completa do arquivo em texto puro.

Se o número te surpreende, o problema é a imagem e não a codificação. Um ícone de 90 KB não é um ícone. Redimensionar e comprimir antes de codificar qualquer coisa muitas vezes responde à pergunta sozinho, e de onde vem de verdade o peso de uma imagem explica por que as dimensões importam mais que o controle deslizante de qualidade.

Vale a pena codificar um SVG em Base64?

Não, e é o único caso em que a resposta não tem nada a ver com limites de tamanho.

Um SVG já é texto. Codificá-lo em Base64 soma um terço ao tamanho sem benefício nenhum e transforma algo legível em ruído. Fazer percent-encoding apenas dos caracteres que quebrariam um url() de CSS — #, <, >, as aspas — deixa tudo mais curto, mantém legível dentro da folha de estilos e comprime muito melhor, porque o gzip encontra repetição em XML e quase nenhuma em Base64. O conversor linkado acima troca sozinho para percent-encoding quando você dá um SVG a ele, e avisa que foi isso que ele fez.

Para um ícone dentro do HTML, melhor ainda: cole o próprio elemento <svg> em vez de qualquer tipo de URI. Aí currentColor funciona, o CSS consegue estilizar os paths e não há custo nenhum de codificação.

O que quebra quando você usa um data URI?

• E-mail. O Gmail e vários outros clientes se recusam a renderizar uma imagem vinda de um data URI, então quem recebe vê um quadrado quebrado. Se o destino é uma caixa de entrada, hospede a imagem e use uma URL normal.
• Content Security Policy. Uma política img-src 'self' bloqueia data URIs de cara. A diretiva precisa de data: adicionado explicitamente, e muitos times de segurança não vão aprovar isso, porque amplia o que uma injeção de script consegue renderizar.
• A busca de imagens. Uma imagem embutida não tem URL, então não há nada que um crawler possa buscar ou indexar. Se você quer que a própria imagem seja encontrável, ela precisa ser um arquivo.

Seu bundler deveria decidir no seu lugar?

É colando data URIs no código-fonte na mão que um repositório acaba com arquivos impossíveis de revisar e imagens que ninguém encontra para atualizar. Mantenha a imagem como um arquivo normal e deixe o bundler embuti-la abaixo de um limite de tamanho: o Vite embute por padrão os assets com menos de 4.096 bytes, e os asset modules do webpack funcionam do mesmo jeito com um corte parecido de poucos kilobytes. Os dois deixam você mudar o número ou forçar qualquer um dos dois comportamentos arquivo por arquivo.

Você fica com código-fonte legível, continua ganhando a otimização dos arquivos pequenos e há um único número para mudar quando o ícone vira uma fotografia. Uma string colada na mão não te dá nada disso. E é também a versão que fica anos no repositório, porque ninguém consegue dizer o que é nem de onde veio.

Última atualização 19 de setembro de 2026