How to use
- Paste the unknown string into the input box.
- The detector runs every decoder and lists the encodings that decode the string cleanly, most likely first.
- Check the preview of the decoded text or bytes and the detected file type for each candidate.
- Once you know the encoding, open its tool page to decode, convert or download the data.
How the detector decides
Every encoding has rules that a string either follows or breaks. The detector runs each decoder on your input. A decoder that meets a character outside its alphabet, an impossible length or misplaced padding is ruled out, and the rest are ranked by how plausible their output looks.
- Character set. Hex uses only
0-9anda-f. Base58 never contains0,O,Iorl. A+or/points to Base64, while-and_point to Base64URL. - Length and padding. Hex needs an even number of digits. Base64 works in groups of 4 characters and Base32 in groups of 8, and their
=padding may only appear at the end. - Readable output. A candidate that decodes to valid UTF-8 made of printable characters is far more likely to be right than one that produces random-looking bytes.
- File signatures. Decoded bytes that start with a known magic number, such as the PNG, JPEG, PDF, ZIP or gzip header, are reported with their file type.
Wrappers such as a data: URI prefix, the Adobe <~ ~> delimiters or uuencode begin lines are understood by the matching decoders. All of this runs in your browser.
Why the result is a ranking, not a certainty
Alphabets overlap a lot. The string 48656c6c6f is hex for Hello, but the same ten characters are also valid Base64, Base36, Base58 and Base62, and each of those produces different bytes. Only the hex reading gives readable text, so hex comes first. A short word like cafe fits almost every alphabet, and nothing in the string itself says which one was meant.
Longer inputs give clearer answers, because accidental matches become unlikely. If no candidate decodes to text or a known file type, the data may be encrypted, compressed or a hash. A SHA-256 hash written in hex is perfectly valid hex, but its bytes look random by design.
Recognizing common encodings by eye
| Encoding | Typical clues |
|---|---|
| Hex | Only 0-9 a-f, even length. 32, 40 or 64 digits often mean an MD5, SHA-1 or SHA-256 hash. |
| Base64 | A-Z a-z 0-9 + /, length a multiple of 4, may end in = or ==. |
| Base64URL | - and _ instead of + and /, usually no padding. Three parts joined by dots is a JWT. |
| Base32 | Uppercase A-Z and 2-7, padded with = to a multiple of 8. |
| Base58 | Letters and digits without 0 O I l. Bitcoin addresses, IPFS hashes starting with Qm. |
| Ascii85, Base85 | A dense mix of letters, digits and punctuation. Ascii85 is sometimes wrapped in <~ ~>. |
Frequently asked questions
How can I tell if a string is Base64?
Why does the detector show more than one encoding?
Many strings are valid in several alphabets at once, especially short ones. The detector lists every encoding that decodes the input without errors and puts the most plausible first, based on readable text and file signatures.
Nothing decodes to readable text. What does that mean?
Can the detector decrypt a string or reverse a hash?
No. Encodings such as Base64 use no key and are reversible by design, which is why they can be detected and decoded. Encrypted data cannot be read without its key, and a hash cannot be turned back into its input.
Is the pasted string sent to a server?
No. Every decoder runs locally in your browser, so tokens, keys and log data never leave your device.