Encoding/Base Detector & Converter

Paste a string and this tool ranks likely encodings/formats (base64, hex, JWT, GUID, hash, JSON, YAML, etc.), with safe decode previews.

Loading interactive simulation...

Detection reports a percentage because certainty is not available 🖖

Every hexadecimal digit — 0 to 9 and a to f — is also a legal Base64 character, so any hex string whose length happens to divide by four is a syntactically valid Base64 string as well. No amount of looking at the alphabet can separate the two, which is why this tool hands you a confidence score rather than a verdict. What actually breaks the tie is structure and meaning: padding, length arithmetic, and whether decoding produces anything sensible. The base64Json sample is the clean case — it decodes to {"name":"Spock","role":"scientist","active":true}, and a guess that yields valid JSON is almost certainly right.

Encoding is not encryption 🖖

When a string looks scrambled, it is tempting to assume it is a secret to crack. But most opaque text is only reshaped, not hidden: Base64 and hex are fully reversible, a GUID is just a unique label, and a hash like SHA-256 is a one-way fingerprint that can never be turned back into its input. This tool sorts strings into those categories so you know whether decoding is even possible in the first place.

Base64 makes data bigger, not smaller 🖖

Base64 is often mistaken for compression, yet it does the opposite: every 3 bytes (24 bits) become 4 printable characters, inflating the data by about 33%, with = signs padding the final group. It exists for a historical reason — early email (MIME over 7-bit SMTP) could not carry raw binary, so attachments had to be re-expressed with a safe 64-character alphabet. That legacy is why images still travel as bloated text inside data: URLs today.

Problems solved in full

Getting to 68 characters from a 49-character ASCII JSON payload and back 5 steps
The input is eyJuYW1lIjoiU3BvY2siLCJyb2xlIjoic2NpZW50aXN0IiwiYWN0aXZlIjp0cnVlfQ==, and the payload under it is the 49-character ASCII JSON {"name":"Spock","role":"scientist","active":true}. The panel prints 68 for Characters and 68 for Bytes. Get to 68 from the 49 without counting the encoded string — then get back.
1. Base64 is a change of base, not a cipher. 64 = 2⁶, so each output character carries 6 bits; 3 input bytes carry 24; and 6 divides 24 exactly. That is the whole format: 3 bytes in, 4 characters out, no remainder.
  
  $2^{24} = 6 4^{4} ⟹ L = 4 ⌈ \frac{n}{3} ⌉$
2. 49 bytes is 16 whole triples with 1 byte over. The triples are the easy part — 16 × 4 = 64 characters, every one of them carrying a full 6 bits.
  
  $n = 49 = 3 \times 16 + 1 ⟹ 16 \times 4 = 64$
3. The orphan byte is where padding comes from. 8 bits is not a multiple of 6, so it is topped up with 4 zero bits to make 12, which is 2 characters, and 2 '=' signs finish the quartet. 64 + 2 + 2 = 68. Each '=' marks a character position that had no bits of its own.
  
  $8 bits + 4 12 = 2 \times 6, p = 2 ⟹ L = 64 + 2 + 2 = 68$
4. Both panel rows read 68, and that agreement says nothing about this string. The base64 alphabet is ASCII, so every character it emits is exactly 1 byte; the Bytes row would track the Characters row for any base64 input at all.
  
  $S = L = 68 (ASCII)$
5. Now reverse it. 68 ÷ 4 = 17 quartets, 17 × 3 = 51 byte slots, minus the 2 slots the padding admits are empty: 49. You have just recovered the payload's size without decoding a single byte of it.
  
  $n = \frac{3 L}{4} - p = \frac{3 \times 68}{4} - 2 = 51 - 2 = 49$
Answer

68 characters for 49 bytes, and the '=' signs are what let you read the 49 straight back off the wrapper. That inversion is the useful half. A base64 string's length depends on its payload's length and on nothing else, so you can state the exact size of something you are not permitted to open — which is a stronger statement than any detector on this page makes about content. The other half is the bill. 4 characters per 3 bytes never improves, so base64 costs 4/3 in the limit: a 1 MiB file arrives as 1,398,104 characters, 341 KiB of pure packaging. This string does worse, at 68/49 = 1.388, because the 2 padding characters are a fixed surcharge and 49 bytes is far too short to spread it thin.

$\frac{L}{n} = \frac{68}{49} = 1.388 ⟶ \frac{4}{3}, 2^{20} B \Rightarrow L = 1398104$
Random bits in a GUID/UUID v4 and identifiers minted before a repeat 6 steps
The input is 550e8400-e29b-41d4-a716-446655440000, which the panel calls a GUID/UUID v4 while also offering to decode it as Base64URL. Work out how many of its bits were actually chosen at random, and how many such identifiers can be minted before a repeat stops being unlikely.
1. Count the shape first: 8-4-4-4-12 hex digits with 4 hyphens between the groups, so 32 + 4 = 36 characters, and the Bytes row matches at 36 because hex digits and hyphens are all ASCII. Note what those 4 hyphens are worth. They sit at fixed positions, so they carry 0 bits.
  
  $L = 32 8 + 4 + 4 + 4 + 12 + 4 = 36 = S$
2. Each hex digit is 4 bits, so the 32 that count hold 128. That is the number usually quoted for a UUID, and for this string it is too high.
  
  $32 \times 4 = 128 bits$
3. Digit 13 and digit 17 are the reason. Digit 13 is 4, and it is the version field — a version-4 UUID is obliged to put a 4 there, so those 4 bits were never a choice. Digit 17 is 'a', which is 1010 in binary, and its leading 2 bits are the variant tag, pinned at 10. 6 bits spent naming the format leaves 122.
  
  $d_{13} = 4 (4 bits), d_{17} = a = 101 0_{2} (2 bits) ⟹ 128 - 6 = 122$
4. The space is therefore 2¹²², about 5.32 × 10³⁶ — not the 3.40 × 10³⁸ that 128 bits would have given.
  
  $N = 2^{122} = 5.32 \times 1 0^{36} (2^{128} = 3.40 \times 1 0^{38})$
5. Repeats follow the birthday rule rather than the size of the space. Drawing n identifiers at random, the chance that some pair matches grows like n²/(2N), and setting that to 0.5 gives n = 1.177√N. The count goes with the square root, which is why the 6 bits lost in step 3 cost a factor of 8 and not a factor of 64.
  
  $1 - e^{- n^{2} /2 N} = 0.5 ⟹ n = 2 N ln 2 = 1.177 N$
6. √N is 2.31 × 10¹⁸, so n comes out at 2.7 × 10¹⁸.
  
  $n = 1.177 \times 2.31 \times 1 0^{18} = 2.7 \times 1 0^{18}$
Answer

122 bits, and 2.7 × 10¹⁸ UUIDs before the chance of any repeat reaches 0.5. Minted at 10⁹ per second that is 86 years, and it is the whole argument for letting every machine generate its own with no registry and no coordination — not a protocol, just a number too large to reach. Set it beside the first problem and the contrast is what this page is for. Base64 packs 6 bits into every character; this string spends 36 characters on 122 bits, which is 3.4 bits each, so the same identifier would fit in 21 base64url characters. The other 15 buy legibility, not information. And the Base64URL decode the panel offers comes back flagged as binary rather than text for the plainest reason available: nothing was ever encoded in there to find.

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

References (1)

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

By the 42Math team · Updated 2026-05-23

Reviewed against published sources. Corrections welcome. Editorial policy · Corrections

All Computing lessons →

Example problems

base64 json - Base64 payload decodes to structured JSON text.
hex text - Hexadecimal payload decodes to readable UTF-8 message.
jwt-like token - JWT-like token exposes base64url header and payload sections.
guid/uuid - GUID/UUID detected as identifier, not decryptable ciphertext.
sha-256 hash - Hash-length fingerprint indicates likely SHA-256 digest.
yaml-like - YAML-like structure identified with key-value and list indentation.
HLS manifest (m3u8) - An HLS playlist — detected as an M3U8 manifest at 100%, with #EXT-X-KEY flagging SAMPLE-AES DRM
MPEG-DASH manifest (MPD) - A DASH manifest — MPEG-DASH MPD with Widevine and PlayReady descriptors, and XML at 92%
markdown - A Markdown document — headings, list markers and a link, detected at 100% with nothing to decode
latex - A LaTeX source file — \documentclass and an environment block, detected at 100%