Por que o Base64 deixa os arquivos maiores?

Este artigo explica por que a saída Base64 é maior que os bytes originais. Não é um guia de segurança. Se você precisa de codificação versus criptografia, use Base64 não é criptografia: o que faz de verdade e como decodificar.

Por que o Base64 precisa de mais espaço?

3 bytes são 24 bits. Base64 divide esses 24 bits em 4 grupos de 6 bits. Cada grupo vira um caractere Base64, então 3 bytes de entrada viram 4 caracteres de saída. Guardado como 1 byte por caractere ASCII, isso é 4 / 3 ≈ 1.333 — um aumento de cerca de 33.3%.

• 3 bytes (24 bits)
• ↓
• Dividir em 4 grupos de 6 bits
• Cada grupo → um caractere Base64
• ↓
• 4 caracteres (muitas vezes 4 bytes de texto)

Um exemplo simples e conferível

Essas codificações batem com o Base64 com preenchimento padrão.

Man

Man

Base64

TWFu

Man são 3 bytes UTF-8/ASCII. TWFu são 4 caracteres: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello são 5 bytes. SGVsbG8= são 8 caracteres, incluindo um =. Em dados pequenos, o preenchimento faz a porcentagem parecer maior que 33%.

Como se calcula o tamanho do Base64?

Para Base64 com preenchimento padrão, encodedLength = 4 × ceil(originalBytes / 3).

Bytes originais	Caracteres Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 ou 2 bytes ainda produzem 4 caracteres. Use a fórmula, não um 33% fixo.

O que o preenchimento “=” significa?

A marca = mostra que o último bloco de 3 bytes não estava completo. 1 byte de entrada usa dois caracteres =; 2 bytes usam um; 3 bytes não usam nenhum. Preenchimento não é criptografia nem um recurso de segurança.

O Base64URL usa menos espaço?

Base64URL troca + por - e / por _, e Codificar e decodificar Base64 omite os = finais na codificação. Isso pode encurtar a string nesses caracteres =. A estrutura de 3 bytes → 4 caracteres continua a mesma, então Base64URL não é um formato binário mais eficiente em espaço.

Por que entradas minúsculas podem crescer mais que 33%?

1 byte → 4 caracteres é um aumento de 300% no comprimento. 2 bytes → 4 é 100%. 3 bytes → 4 é cerca de 33.3%. Conforme n cresce, o preenchimento importa menos e o custo extra se aproxima de cerca de 33%. Base64 não fica 33% maior em todos os casos.

Por que uma Data URL Base64 é ainda maior?

Uma Data URL acrescenta um prefixo como data:image/png;base64, antes da carga. Num arquivo minúsculo esse prefixo pode dominar a porcentagem. Codificar e decodificar Base64 pode emitir Base64 cru ou uma Data URL; a saída Data URL usa o alfabeto padrão.

Base64 vs binário: qual é menor?

O binário cru é mais eficiente em espaço para transporte e armazenamento. Base64 é maior, mas seguro como texto em JSON, e-mail e outros caminhos só de texto. É codificação de binário para texto, não compressão.

O Base64 comprime arquivos?

Não. Base64 não é um formato de compressão. O texto codificado costuma ser maior que os bytes originais. Se depois você aplicar gzip ou Brotli nesse texto, parte da redundância pode encolher — o resultado depende dos dados e do compressor. gzip não remove por completo o custo extra do Base64.

O que acontece se o Base64 receber gzip?

A compressão HTTP pode reduzir alguns padrões repetidos no texto Base64. JPEG, PNG ou ZIP costumam comprimir mal mesmo como bytes crus, e Base64-depois-gzip continua dependendo do caso. Não existe um porcentual extra universal depois do gzip.

Você deveria guardar arquivos como Base64?

Base64 pode caber binário num campo JSON, num asset pequeno em linha, numa API só de texto, em copiar e colar ou numa Data URL. Em arquivos grandes, armazenamento, memória e tamanho da carga todos crescem. Isso não é “nunca use Base64 para arquivos”.

Por que o Base64 é comum em APIs JSON?

JSON não tem um tipo nativo de binário cru, então as APIs costumam colocar bytes numa string Base64. Para arquivos grandes, multipart/form-data, armazenamento de objetos ou um upload binário direto podem encaixar melhor. Nenhuma escolha é sempre a melhor.

Por que o Base64 é usado em e-mail?

MIME pode usar Base64 para um anexo binário viajar como caracteres seguros para texto. O mesmo custo extra de tamanho ainda vale. É uma representação de transporte, não um arquivo menor.

Quando o tamanho extra vale a pena?

O tamanho extra pode valer a pena quando o binário precisa ficar dentro de texto, a carga é pequena, uma API exige Base64 ou você precisa de uma Data URL. Para mídia grande, prefira binário cru quando o sistema permitir.

Quando você deveria evitar Base64?

Pule em arquivos grandes, banda apertada, transferências frequentes ou quando já existe um caminho binário — situacional, não “Base64 é má prática”.

Comprimentos de Base64 com preenchimento que você pode conferir

Contagens de bytes originais e contagens de caracteres Base64 com preenchimento padrão:

Bytes originais	Caracteres Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Todas as linhas seguem 4 × ceil(n / 3). São contagens de caracteres Base64.

Exemplo: de que tamanho fica um arquivo de 1,000 bytes?

4 × ceil(1000 / 3). ceil(333.333…) = 334, e 4 × 334 = 1336. Então 1,000 bytes viram 1,336 caracteres Base64. Guardados como UTF-8/ASCII, cada caractere costuma ser 1 byte — não trate 1,336 como uma contagem exata de bytes na memória.

O Base64 pode usar mais memória do que o tamanho do arquivo sugere?

Alguns ambientes guardam strings com mais de 1 byte por caractere, e codificar/decodificar pode manter um buffer e uma string ao mesmo tempo. O uso de memória não é exatamente o comprimento em caracteres.

Um guia simples de decisão por tamanho

Se o sistema aceita binário cru, prefira-o pelo tamanho. Se só texto é permitido, Base64 pode caber. Para uma carga grande, procure um caminho de upload binário. Para texto seguro em URL, considere Base64URL — a expansão de 3 para 4 permanece.

• Precisa enviar dados binários
• ↓
• Binário cru permitido? Prefira binário pelo tamanho
• Campo só de texto? Base64 pode ser adequado
• Carga grande? Procure um caminho de upload binário
• Precisa de texto seguro para URL? Considere Base64URL
• ↓
• Espere cerca de 33% a mais de texto em entradas grandes

Codifique ou decodifique Base64 no navegador

NEXNARA Codificar e decodificar Base64 codifica e decodifica texto, e pode transformar um arquivo em Base64 ou uma Data URL e devolver Base64 a um arquivo.

O texto usa bytes UTF-8 e depois Base64 — não só ASCII. Escolha Standard ou Base64URL. A saída de arquivo pode ser Base64 cru ou uma Data URL (alfabeto padrão). Entrada inválida é recusada. Bytes que não são UTF-8 precisam ir para arquivo, não para decodificação de texto.

Arquivos acima de 10 MB podem deixar a aba lenta (aviso). Arquivos acima de 32 MB são bloqueados.

A codificação e a decodificação acontecem no seu navegador. O arquivo não é enviado a um servidor da NEXNARA nesta ferramenta. Anúncios e outros recursos do site ainda usam a rede.

Cole texto ou um arquivo em Codificar e decodificar Base64 e compare os bytes originais com o comprimento codificado.

FAQ

Por que o Base64 aumenta o tamanho do arquivo?

Ele mapeia 3 bytes (24 bits) para 4 caracteres (4 × 6 bits). Guardado como texto, isso é cerca de um terço a mais em entradas grandes.

O Base64 é sempre 33% maior?

Não. Entradas grandes se aproximam de cerca de 33.3%. Entradas minúsculas podem crescer mais por causa do preenchimento. Use 4 × ceil(n / 3).

Quanto maior o Base64 é em relação ao binário?

O comprimento com preenchimento padrão é 4 × ceil(n / 3) caracteres. Um prefixo de Data URL acrescenta mais.

A compressão Base64 reduz o tamanho do arquivo?

Base64 não comprime. gzip ou Brotli no texto codificado podem encolher uma parte; não apagam o custo extra em todos os casos.

O Base64URL usa menos espaço?

Ele pode omitir o preenchimento =, então a string pode ficar 0–2 caracteres mais curta. A estrutura de codificação de 3 para 4 é a mesma.

Devo usar Base64 para arquivos grandes?

Só se você precisar de texto. Para transferências grandes ou frequentes, um caminho binário costuma ser menor. Base64 nem sempre está errado em APIs.