Detector y conversor de codificación/base

Pega una cadena y esta herramienta clasifica las codificaciones/formatos probables (base64, hex, JWT, GUID, hash, JSON, YAML, etc.), con vistas previas de decodificación seguras.

Cargando simulación interactiva...

La detección da un porcentaje porque la certeza no está disponible 🖖

Cada dígito hexadecimal — del 0 al 9 y de la a a la f — es también un carácter Base64 válido, así que cualquier cadena hexadecimal cuya longitud resulte divisible por cuatro es además una cadena Base64 sintácticamente válida. Mirar el alfabeto no puede separar las dos, y por eso esta herramienta te entrega una puntuación de confianza en lugar de un veredicto. Lo que de verdad desempata es la estructura y el significado: el relleno, la aritmética de la longitud y si al decodificar sale algo con sentido. La muestra base64Json es el caso limpio — se decodifica como {"name":"Spock","role":"scientist","active":true}, y una conjetura que produce JSON válido acierta casi seguro.

Codificar no es cifrar 🖖

Cuando una cadena parece revuelta, es tentador suponer que es un secreto que hay que descifrar. Pero la mayoría del texto opaco solo está reformado, no oculto: Base64 y hexadecimal son totalmente reversibles, un GUID es apenas una etiqueta única, y un hash como SHA-256 es una huella unidireccional que nunca puede volver a convertirse en su entrada original. Esta herramienta clasifica las cadenas en esas categorías para que sepas si la decodificación siquiera es posible.

Base64 agranda los datos, no los reduce 🖖

A menudo se confunde Base64 con la compresión, pero hace lo contrario: cada 3 bytes (24 bits) se convierten en 4 caracteres imprimibles, lo que infla los datos alrededor de un 33%, con signos = rellenando el último grupo. Existe por una razón histórica: el correo electrónico primitivo (MIME sobre SMTP de 7 bits) no podía transportar binario en bruto, así que los adjuntos debían reexpresarse con un alfabeto seguro de 64 caracteres. Esa herencia explica por qué las imágenes aún viajan como texto inflado dentro de URLs data:.

Problemas resueltos al detalle

Llegar a 68 caracteres desde una carga útil JSON ASCII de 49 caracteres y viceversa 5 pasos
La entrada es eyJuYW1lIjoiU3BvY2siLCJyb2xlIjoic2NpZW50aXN0IiwiYWN0aXZlIjp0cnVlfQ== y la carga útil subyacente es el JSON ASCII de 49 caracteres {"name":"Spock","role":"scientist","active":true}. El panel muestra 68 para Caracteres y 68 para Bytes. Llega a 68 a partir de los 49 sin contar la cadena codificada y, a continuación, deshaz el camino.
1. Base64 es un cambio de base, no un cifrado. 64 = 2⁶, por lo que cada carácter de salida lleva 6 bits; 3 bytes de entrada llevan 24; y 6 divide a 24 de forma exacta. Ese es todo el formato: entran 3 bytes, salen 4 caracteres, sin resto.
  
  $2^{24} = 6 4^{4} ⟹ L = 4 ⌈ \frac{n}{3} ⌉$
2. 49 bytes son 16 tríos completos y 1 byte sobrante. Los tríos son la parte fácil: 16 × 4 = 64 caracteres, cada uno de los cuales lleva 6 bits completos.
  
  $n = 49 = 3 \times 16 + 1 ⟹ 16 \times 4 = 64$
3. El byte huérfano es de donde proviene el relleno. 8 bits no es un múltiplo de 6, por lo que se completa con 4 bits a cero para llegar a 12, que son 2 caracteres, y 2 signos '=' completan el cuarteto. 64 + 2 + 2 = 68. Cada '=' marca una posición de carácter que no tenía bits propios.
  
  $8 bits + 4 12 = 2 \times 6, p = 2 ⟹ L = 64 + 2 + 2 = 68$
4. Ambas filas del panel muestran 68, y esa coincidencia no dice nada sobre esta cadena. El alfabeto base64 es ASCII, por lo que cada carácter que emite es exactamente de 1 byte; la fila Bytes coincidiría con la fila Caracteres para cualquier entrada base64.
  
  $S = L = 68 (ASCII)$
5. Ahora haz el proceso inverso. 68 ÷ 4 = 17 cuartetos, 17 × 3 = 51 huecos de byte, menos los 2 huecos que el relleno indica que están vacíos: 49. Acabas de recuperar el tamaño de la carga útil sin decodificar ni un solo byte de ella.
  
  $n = \frac{3 L}{4} - p = \frac{3 \times 68}{4} - 2 = 51 - 2 = 49$
Respuesta

68 caracteres para 49 bytes, y los signos '=' son los que te permiten recuperar los 49 directamente del envoltorio. Esa inversión es la mitad útil. La longitud de una cadena base64 depende de la longitud de su carga útil y de nada más, de modo que puedes indicar el tamaño exacto de algo que no tienes permitido abrir, lo cual es una afirmación más contundente que la de cualquier detector de esta página sobre el contenido. La otra mitad es la cuenta a pagar. 4 caracteres por cada 3 bytes nunca mejora, por lo que base64 cuesta 4/3 en el límite: un archivo de 1 MiB llega como 1.398.104 caracteres, 341 KiB de puro empaquetado. Esta cadena sale peor parada, con 68/49 = 1,388, porque los 2 caracteres de relleno son un recargo fijo y 49 bytes es demasiado corto para diluirlo.

$\frac{L}{n} = \frac{68}{49} = 1.388 ⟶ \frac{4}{3}, 2^{20} B \Rightarrow L = 1398104$
Bits aleatorios en un GUID/UUID v4 e identificadores generados antes de una repetición 6 pasos
La entrada es 550e8400-e29b-41d4-a716-446655440000, a la cual el panel llama GUID/UUID v4 mientras que también ofrece decodificarla como Base64URL. Calcula cuántos de sus bits se eligieron realmente al azar y cuántos identificadores de este tipo se pueden generar antes de que una repetición deje de ser improbable.
1. Cuenta primero la estructura: 8-4-4-4-12 dígitos hexadecimales con 4 guiones entre los grupos, de modo que 32 + 4 = 36 caracteres, y la fila Bytes coincide en 36 porque los dígitos hexadecimales y los guiones son todos ASCII. Observa lo que valen esos 4 guiones. Se sitúan en posiciones fijas, por lo que llevan 0 bits.
  
  $L = 32 8 + 4 + 4 + 4 + 12 + 4 = 36 = S$
2. Cada dígito hexadecimal son 4 bits, por lo que los 32 que cuentan albergan 128. Ese es el número que se suele citar para un UUID, y para esta cadena es demasiado alto.
  
  $32 \times 4 = 128 bits$
3. El dígito 13 y el dígito 17 son la razón. El dígito 13 es 4 y es el campo de versión: un UUID versión 4 está obligado a poner un 4 ahí, por lo que esos 4 bits nunca fueron una elección. El dígito 17 es 'a', que es 1010 en binario, y sus 2 bits iniciales son la etiqueta de variante, fijada en 10. Gastar 6 bits en nombrar el formato deja 122.
  
  $d_{13} = 4 (4 bits), d_{17} = a = 101 0_{2} (2 bits) ⟹ 128 - 6 = 122$
4. El espacio es por tanto 2¹²², aproximadamente 5,32 × 10³⁶, no los 3,40 × 10³⁸ que habrían dado 128 bits.
  
  $N = 2^{122} = 5.32 \times 1 0^{36} (2^{128} = 3.40 \times 1 0^{38})$
5. Las repeticiones siguen la regla del cumpleaños en lugar del tamaño del espacio. Al extraer n identificadores al azar, la probabilidad de que algún par coincida crece como n²/(2N), y fijar eso en 0,5 da n = 1,177√N. El recuento evoluciona con la raíz cuadrada, motivo por el cual los 6 bits perdidos en el paso 3 cuestan un factor de 8 y no un factor de 64.
  
  $1 - e^{- n^{2} /2 N} = 0.5 ⟹ n = 2 N ln 2 = 1.177 N$
6. √N es 2,31 × 10¹⁸, por lo que n resulta ser 2,7 × 10¹⁸.
  
  $n = 1.177 \times 2.31 \times 1 0^{18} = 2.7 \times 1 0^{18}$
Respuesta

122 bits, y 2,7 × 10¹⁸ UUIDs antes de que la probabilidad de cualquier repetición alcance 0,5. Generados a razón de 10⁹ por segundo eso son 86 años, y es todo el argumento para permitir que cada máquina genere el suyo propio sin registro ni coordinación: no un protocolo, simplemente un número demasiado grande como para alcanzarlo. Ponlo junto al primer problema y el contraste es el propósito de esta página. Base64 empaqueta 6 bits en cada carácter; esta cadena emplea 36 caracteres para 122 bits, lo que supone 3,4 bits cada uno, por lo que el mismo identificador cabría en 21 caracteres base64url. Los otros 15 compran legibilidad, no información. Y la decodificación Base64URL que ofrece el panel vuelve marcada como binario en lugar de texto por la razón más simple disponible: nunca hubo nada codificado ahí dentro que encontrar.

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

Referencias (1)

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

Por el equipo de 42Math · Actualizado 2026-05-23

Contrastado con fuentes publicadas. Se agradecen correcciones. Política editorial · Correcciones

Todas las lecciones de Informática →

Problemas de ejemplo

JSON en base64 - La carga en Base64 se decodifica en texto JSON estructurado.
texto en hex - La carga hexadecimal se decodifica en un mensaje UTF-8 legible.
token tipo JWT - Un token tipo JWT expone las secciones de encabezado y carga en base64url.
guid/uuid - Se detecta un GUID/UUID como identificador, no como texto cifrado descifrable.
hash SHA-256 - Una huella con longitud de hash indica probablemente un resumen SHA-256.
tipo YAML - Se identifica una estructura tipo YAML con pares clave-valor y sangría de listas.
manifiesto HLS (m3u8) - Una lista HLS — manifiesto M3U8 detectado al 100%, con #EXT-X-KEY señalando DRM SAMPLE-AES
manifiesto MPEG-DASH (MPD) - Un manifiesto DASH — MPD de MPEG-DASH con descriptores Widevine y PlayReady, y XML al 92%
markdown - Un documento Markdown — encabezados, viñetas y un enlace, detectado al 100% y sin nada que decodificar
latex - Un archivo fuente LaTeX — \documentclass y un bloque de entorno, detectado al 100%