Detector e conversor de codificação/base

Cole uma string e esta ferramenta classifica as codificações/formatos prováveis (base64, hex, JWT, GUID, hash, JSON, YAML etc.), com pré-visualizações de decodificação seguras.

A carregar a simulação interativa...

A detecção dá uma percentagem porque a certeza não está disponível 🖖

Cada dígito hexadecimal — 0 a 9 e a a f — é também um carácter Base64 legal, portanto qualquer cadeia hexadecimal cujo comprimento por acaso se divida por quatro é igualmente uma cadeia Base64 sintaticamente válida. Nenhuma observação do alfabeto consegue separar as duas, e é por isso que esta ferramenta lhe dá uma pontuação de confiança em vez de um veredicto. O que realmente desempata é a estrutura e o significado: o enchimento, a aritmética do comprimento e se a descodificação produz algo com sentido. A amostra base64Json é o caso limpo — descodifica para {"name":"Spock","role":"scientist","active":true}, e um palpite que dá JSON válido está quase certamente correcto.

Codificar não é criptografar 🖖

Quando uma cadeia parece embaralhada, é tentador supor que seja um segredo a decifrar. Mas a maior parte do texto opaco está apenas remodelado, não escondido: Base64 e hexadecimal são totalmente reversíveis, um GUID é só um rótulo único, e um hash como SHA-256 é uma impressão digital de mão única que nunca pode voltar a ser sua entrada original. Esta ferramenta classifica as cadeias nessas categorias para que você saiba se a decodificação é sequer possível.

Base64 aumenta os dados, não os reduz 🖖

Base64 é muitas vezes confundido com compressão, mas faz o oposto: cada 3 bytes (24 bits) viram 4 caracteres imprimíveis, inflando os dados em cerca de 33%, com sinais = preenchendo o último grupo. Ele existe por uma razão histórica: o e-mail primitivo (MIME sobre SMTP de 7 bits) não conseguia transportar binário bruto, então os anexos precisavam ser reexpressos com um alfabeto seguro de 64 caracteres. Essa herança explica por que as imagens ainda viajam como texto inflado dentro de URLs data:.

Problemas resolvidos na íntegra

Chegar a 68 carateres a partir de um payload JSON ASCII de 49 carateres e voltar 5 passos
A entrada é eyJuYW1lIjoiU3BvY2siLCJyb2xlIjoic2NpZW50aXN0IiwiYWN0aXZlIjp0cnVlfQ== e a carga útil sob ela é o JSON ASCII de 49 carateres {"name":"Spock","role":"scientist","active":true}. O painel apresenta 68 para Carateres e 68 para Bytes. Chegue a 68 a partir de 49 sem contar a cadeia codificada — e depois faça o caminho inverso.
1. O Base64 é uma mudança de base, não uma cifra. 64 = 2⁶, pelo que cada carater de saída transporta 6 bits; 3 bytes de entrada transportam 24; e 6 divide 24 exatamente. É este todo o formato: 3 bytes de entrada, 4 carateres de saída, sem resto.
  
  $2^{24} = 6 4^{4} ⟹ L = 4 ⌈ \frac{n}{3} ⌉$
2. 49 bytes são 16 triplos completos com 1 byte sobrante. Os triplos são a parte fácil — 16 × 4 = 64 carateres, cada um deles a transportar 6 bits completos.
  
  $n = 49 = 3 \times 16 + 1 ⟹ 16 \times 4 = 64$
3. O byte órfão é a origem do preenchimento. 8 bits não é um múltiplo de 6, pelo que é complementado com 4 bits a zero para perfazer 12, o que corresponde a 2 carateres, e 2 sinais '=' completam o quarteto. 64 + 2 + 2 = 68. Cada '=' assinala uma posição de carater que não tinha bits próprios.
  
  $8 bits + 4 12 = 2 \times 6, p = 2 ⟹ L = 64 + 2 + 2 = 68$
4. Ambas as linhas do painel indicam 68, e essa concordância nada diz sobre esta cadeia. O alfabeto base64 é ASCII, pelo que cada carater emitido é exatamente 1 byte; a linha Bytes acompanharia a linha Carateres para qualquer entrada em base64.
  
  $S = L = 68 (ASCII)$
5. Agora faça o inverso. 68 ÷ 4 = 17 quartetos, 17 × 3 = 51 posições de byte, menos as 2 posições que o preenchimento indica estarem vazias: 49. Acabou de recuperar o tamanho da carga útil sem descodificar um único byte da mesma.
  
  $n = \frac{3 L}{4} - p = \frac{3 \times 68}{4} - 2 = 51 - 2 = 49$
Resposta

68 carateres para 49 bytes, e os sinais '=' são o que permite ler o 49 diretamente a partir do invólucro. Essa inversão é a metade útil. O comprimento de uma cadeia base64 depende do comprimento da sua carga útil e de mais nada, pelo que pode indicar o tamanho exato de algo que não tem permissão para abrir — o que é uma afirmação mais forte do que qualquer detetor nesta página faz sobre o conteúdo. A outra metade é a conta a pagar. 4 carateres por 3 bytes nunca melhora, pelo que o base64 custa 4/3 no limite: um ficheiro de 1 MiB chega como 1 398 104 carateres, 341 KiB de puro empacotamento. Esta cadeia faz pior, com 68/49 = 1,388, porque os 2 carateres de preenchimento são uma sobretaxa fixa e 49 bytes é demasiado curto para a diluir.

$\frac{L}{n} = \frac{68}{49} = 1.388 ⟶ \frac{4}{3}, 2^{20} B \Rightarrow L = 1398104$
Bits aleatórios num GUID/UUID v4 e identificadores criados antes de uma repetição 6 passos
A entrada é 550e8400-e29b-41d4-a716-446655440000, que o painel classifica como GUID/UUID v4 ao mesmo tempo que oferece a opção de a descodificar como Base64URL. Calcule quantos dos seus bits foram efetivamente escolhidos ao acaso e quantos identificadores deste tipo podem ser gerados antes que uma repetição deixe de ser improvável.
1. Conte primeiro a estrutura: 8-4-4-4-12 dígitos hexadecimais com 4 hífenes entre os grupos, ou seja, 32 + 4 = 36 carateres, e a linha Bytes coincide em 36 porque os dígitos hexadecimais e os hífenes são todos ASCII. Note o valor desses 4 hífenes. Estão em posições fixas, pelo que transportam 0 bits.
  
  $L = 32 8 + 4 + 4 + 4 + 12 + 4 = 36 = S$
2. Cada dígito hexadecimal tem 4 bits, pelo que os 32 que contam contêm 128. Esse é o número habitualmente indicado para um UUID, e para esta cadeia é demasiado elevado.
  
  $32 \times 4 = 128 bits$
3. O dígito 13 e o dígito 17 são a razão. O dígito 13 é 4 e corresponde ao campo da versão — um UUID de versão 4 é obrigado a colocar um 4 nessa posição, pelo que esses 4 bits nunca foram uma escolha. O dígito 17 é 'a', que é 1010 em binário, e os seus 2 bits iniciais são a etiqueta de variante, fixa em 10. Gastar 6 bits a definir o formato deixa 122.
  
  $d_{13} = 4 (4 bits), d_{17} = a = 101 0_{2} (2 bits) ⟹ 128 - 6 = 122$
4. O espaço é, portanto, 2¹²², cerca de 5,32 × 10³⁶ — e não os 3,40 × 10³⁸ que 128 bits teriam proporcionado.
  
  $N = 2^{122} = 5.32 \times 1 0^{36} (2^{128} = 3.40 \times 1 0^{38})$
5. As repetições seguem a regra do aniversário em vez do tamanho do espaço. Ao extrair n identificadores ao acaso, a probabilidade de algum par coincidir cresce como n²/(2N), e igualar essa probabilidade a 0,5 resulta em n = 1,177√N. A contagem varia com a raiz quadrada, razão pela qual os 6 bits perdidos no passo 3 custam um fator de 8 e não um fator de 64.
  
  $1 - e^{- n^{2} /2 N} = 0.5 ⟹ n = 2 N ln 2 = 1.177 N$
6. √N é 2,31 × 10¹⁸, pelo que n resulta em 2,7 × 10¹⁸.
  
  $n = 1.177 \times 2.31 \times 1 0^{18} = 2.7 \times 1 0^{18}$
Resposta

122 bits, e 2,7 × 10¹⁸ UUIDs antes que a probabilidade de qualquer repetição atinja 0,5. Gerados a 10⁹ por segundo, isso equivale a 86 anos, sendo este todo o argumento para permitir que cada máquina gere o seu próprio sem registo e sem coordenação — não é um protocolo, apenas um número demasiado grande para ser alcançado. Coloque este problema ao lado do primeiro e o contraste revela a finalidade desta página. O Base64 agrupa 6 bits em cada carater; esta cadeia gasta 36 carateres em 122 bits, o que equivale a 3,4 bits por carater, pelo que o mesmo identificador caberia em 21 carateres base64url. Os outros 15 compram legibilidade, não informação. E a descodificação em Base64URL oferecida pelo painel regressa assinalada como binário em vez de texto pela razão mais simples possível: nunca nada foi codificado ali para ser encontrado.

$n_{1/2} = 1.177 2^{122} = 2.7 \times 1 0^{18}, ⌈ \frac{122}{6} ⌉ = 21$

Referências (1)

The alphabets and padding rules the detector reasons about, normatively: S. Josefsson, "The Base16, Base32, and Base64 Data Encodings." RFC 4648, IETF, 2006.

Pela equipa 42Math · Atualizado 2026-05-23

Verificado com fontes publicadas. Correções bem-vindas. Política editorial · Correções

Todas as lições de Computação →

Problemas de exemplo

json em base64 - O payload em Base64 é decodificado em um texto JSON estruturado.
texto em hex - O payload hexadecimal é decodificado em uma mensagem UTF-8 legível.
token tipo JWT - Um token do tipo JWT expõe as seções de header e payload em base64url.
guid/uuid - GUID/UUID detectado como identificador, não como texto cifrado decifrável.
hash sha-256 - A impressão digital com esse comprimento de hash indica um provável digest SHA-256.
tipo yaml - Estrutura do tipo YAML identificada, com pares chave-valor e indentação de listas.
manifesto HLS (m3u8) - Uma playlist HLS — manifesto M3U8 detetado a 100%, com #EXT-X-KEY a assinalar DRM SAMPLE-AES
manifesto MPEG-DASH (MPD) - Um manifesto DASH — MPD MPEG-DASH com descritores Widevine e PlayReady, e XML a 92%
markdown - Um documento Markdown — títulos, marcadores e uma ligação, detetado a 100% e sem nada para descodificar
latex - Um ficheiro-fonte LaTeX — \documentclass e um bloco de ambiente, detetado a 100%