Base64 vs URL encoding: qual é a diferença?

“Codificação Base64” e “URL encoding” soam como se devessem fazer coisas parecidas — ambos convertem dados para uma representação diferente usando apenas caracteres seguros. Mas resolvem problemas diferentes, produzem saídas muito diferentes e são usados em lugares diferentes. Confundir os dois é uma forma confiável de quebrar APIs, estragar links e perder horas em depuração.

As duas codificações lado a lado

	Base64	URL encoding (percent-encoding)
Propósito	Representar dados binários como texto	Tornar strings seguras para URLs
Alfabeto	64 caracteres (A-Z, a-z, 0-9, +, /)	Qualquer ASCII imprimível, usa %XX para caracteres inseguros
Aumento de tamanho	Exatamente +33%	Variável (tipicamente +0-200% dependendo do conteúdo)
Usado em	E-mail, JSON, data URIs, JWTs	URLs, envios de formulário, query strings
Entrada	Bytes	Texto (geralmente uma string com caracteres especiais)

O que o URL encoding realmente faz

URL encoding — formalmente percent-encoding, definido na RFC 3986 — é o esquema que permite colocar texto arbitrário em uma URL sem quebrá-la.

URLs têm estrutura:

https://example.com/search?q=coffee&lang=en

Certos caracteres têm significado especial: ? separa o caminho da query string, & separa parâmetros, = separa chave de valor, / separa segmentos de caminho, # inicia o fragmento.

Se você quiser incluir qualquer um desses como dado — por exemplo, uma consulta por “A & B” — precisa escapá-los para que o parser de URL não se confunda. URL encoding faz isso substituindo cada caractere especial por % seguido do código ASCII hexadecimal de dois dígitos:

• Espaço → %20 (ou às vezes + em query strings)
• & → %26
• = → %3D
• # → %23

Então A & B vira A%20%26%20B. Caracteres seguros (letras, dígitos, -, _, ., ~) passam intactos. Para entrada já composta mostly de caracteres seguros, a saída é apenas um pouco mais longa. Para entrada cheia de caracteres especiais, pode ficar muito maior.

O que o Base64 realmente faz

Base64 é completamente diferente. Pega bytes — não necessariamente texto — e produz texto usando apenas os 64 caracteres do seu alfabeto. Cada 3 bytes de entrada viram 4 caracteres de saída, sempre.

Base64 não se importa com o que a entrada é. Trata tudo como bytes e emite uma string segura para usar em praticamente qualquer lugar que espera texto. A saída é exatamente 33% maior que a entrada (mais o preenchimento com = até o múltiplo de 4 mais próximo).

Base64 é a primeira escolha quando você precisa passar dados binários — uma imagem PNG, um arquivo zip, um blob criptografado — por um canal só de texto, como e-mail ou JSON. URL encoding não consegue fazer isso direito: foi projetado para transformação de texto em texto, não para binário arbitrário.

A sobreposição: quando você precisa dos dois

Há um cenário específico em que os dois aparecem juntos: colocar dados binários dentro de uma URL.

Digamos que você tenha uma imagem minúscula (20 bytes de PNG) e queira embutir num parâmetro de URL:

1. Codifique a imagem em Base64 → você tem uma string de 28 caracteres
2. Codifique a string Base64 como URL → os caracteres +, / e = viram %2B, %2F, %3D

A URL final fica um pouco mais longa, mas agora é segura em qualquer contexto.

Porque essa combinação é tão comum, existe uma variante chamada Base64 URL-safe que usa - e _ em vez de + e / (seguros em URLs sem escape) e descarta o preenchimento =:

• Base64 padrão: a+b/c=
• Base64 URL-safe: a-b_c

JWTs (JSON Web Tokens) usam Base64 URL-safe — por isso você vê strings como eyJhbGciOiJIUzI1NiJ9 sem nenhum + ou /.

Exemplo lado a lado

Entrada: o texto Hello, world! (13 bytes)

URL encoding (escapa a vírgula, espaço e !):

Hello%2C%20world%21

Comprimento: 19 caracteres. Ainda legível.

Codificação Base64 (converte os 13 bytes para texto):

SGVsbG8sIHdvcmxkIQ==

Comprimento: 20 caracteres. Não legível.

Base64 URL-safe (sem caracteres que precisam de escape):

SGVsbG8sIHdvcmxkIQ

Comprimento: 18 caracteres. Usado em JWTs e IDs compactos.

Quando usar URL encoding

Use quando você precisa embutir entrada de usuário num caminho de URL ou query string — qualquer coisa que um humano digita numa caixa de busca precisa de URL encoding antes de virar parte de uma URL. Também para escapar caracteres especiais em envios de formulário (HTML faz isso por padrão) e ao construir URLs de API REST com parâmetros dinâmicos.

Não use URL encoding para dados binários. URL encoding não lida bem com bytes arbitrários — qualquer coisa além de ASCII fica estranha e desperdiça espaço em escapes %.

Quando usar Base64

Use quando precisar transmitir dados binários por um canal só de texto (JSON, e-mail, XML), embutir pequenos arquivos em HTML ou CSS via data URIs, trabalhar com tokens, certificados ou dados criptográficos que chegam como bytes mas precisam ser armazenados como texto, ou compartilhar arquivos por copiar-e-colar onde um binário não sobreviveria.

Não use Base64 quando os dados já são texto e você só precisa escapar caracteres especiais para uma URL — aí URL encoding é a ferramenta certa. E se tamanho importa e você tem um canal seguro para binário, envie os bytes diretamente em vez de inflar em 33%.

Cenários comuns de confusão

“Codifiquei uma string em Base64 para colocar numa URL, e ainda está quebrada.” A saída Base64 contém +, / e = — todos com significado especial em URLs. Você precisa codificar a string Base64 como URL, ou usar a variante Base64 URL-safe.

“Fiz URL encoding de um arquivo, mas está corrompido.” URL encoding trata a entrada como texto, então bytes não-ASCII são interpretados de forma inconsistente dependendo da codificação assumida. Para arquivos binários, Base64 primeiro, depois URL encoding do resultado se necessário.

“A API diz para codificar a senha em Base64 para Basic Auth.” HTTP Basic Authentication pega usuario:senha, codifica essa string inteira em Base64 e coloca no cabeçalho Authorization. Isso não é porque Base64 é seguro (não é) — é porque o cabeçalho precisa sobreviver por sistemas que podem distorcer texto bruto. A segurança vem do HTTPS, não do Base64.

Um fluxo prático

Nossa ferramenta Base64 cuida de codificação e decodificação:

• Cole texto → receba Base64 (para embutir em JSON, data URIs, etc.)
• Cole Base64 → receba texto (para ler JWTs, decodificar tokens, etc.)
• Faça upload de um arquivo → receba Base64 (para transmitir o arquivo como texto)

Para URL encoding, toda linguagem tem um one-liner:

• JavaScript: encodeURIComponent(str) / decodeURIComponent(str)
• Python: urllib.parse.quote(str) / urllib.parse.unquote(str)
• PHP: urlencode($str) / urldecode($str)
• Ruby: CGI.escape(str) / CGI.unescape(str)

Para cenários combinados (dados binários em uma URL), o padrão é: Base64 primeiro, depois URL encoding se necessário — ou use Base64 URL-safe diretamente.

A regra prática é simples: URL encoding para texto-em-URL, Base64 para bytes-em-texto. Uma vez internalizado isso, a confusão desaparece. E a ferramenta Base64 está lá sempre que você precisar do tradutor de bytes-em-texto, rodando localmente para que até tokens sensíveis fiquem no seu dispositivo.