Encoding Auto-Decoder

Paste an encoded string and this tool works out what it is, decodes it, and keeps going if the result is encoded again. Everything runs in your browser tab with plain JavaScript: the text you paste is never sent to a server, never put in the page address, and never passed to analytics.

That matters for CTF work, where the string in front of you may be challenge data you would rather not paste into a random website. Nothing you paste is stored. The only things kept on your device are the flag prefixes you choose to add and which result tabs you have pinned (both in this browser's localStorage) and, if you hand a value to or from another CTF Lab tool, that single value in IndexedDB for up to 30 minutes.

Each format has a detector that returns a score from 0 to 100 and a list of reasons. The score combines three things: how much of the input fits the format's character set (up to 50 points), whether the length obeys the format's rule — a multiple of 4 for Base64, 8 for Base32, even for hex (up to 30), and format-specific markers such as = padding, 0x prefixes, %XX pairs or a begin line (up to 20).

Very short strings are penalised because almost anything is valid in several formats, and unpadded lowercase words are down-weighted so ordinary text is not mistaken for Base64. Candidates scoring 50 or more are explored; the ranked list and the evidence behind each score are always shown, so you can judge and override.

Challenge authors stack encodings: a flag is hex-encoded, then Base64-encoded, then ROT13'd. Auto-chain decodes the outermost layer, re-runs detection on the result, and repeats up to 12 layers deep, showing every intermediate step with its entropy, printable share and any flag found.

Worked example: NjY2YzYxNjc3YjY4Njk3ZA== is Base64 for the hex string 666c61677b68697d, which is hex for flag{hi}. The tool shows exactly that three-row chain and stops at the flag. When a string is valid in two formats at once — deadbeef is both hex and Base64 — the Branch Explorer follows both and lists each reading under “Other paths”. If a reading ends in readable text it becomes the main chain; if none does, the main chain stays on the input and says it is ambiguous.

Base64 turns arbitrary bytes into 64 printable characters (A–Z, a–z, 0–9, + and /) so binary data can travel through systems built for text: email attachments, data URIs, HTTP Basic authentication headers and JSON fields. Every 3 input bytes become 4 output characters, which is why the output is about a third larger and why = padding appears when the input is not a multiple of 3 bytes.

It is an encoding, not encryption: anyone can reverse it, which is exactly why CTF authors use it as a first layer of obfuscation. The URL-safe variant swaps + and / for - and _ so the text survives in links and file names, and many implementations drop the = padding, so a string whose length is not a multiple of 4 can still be valid Base64.

Hex writes each byte as two digits (0–9, a–f), doubling the size but staying easy to read and type; it dominates hashes, memory dumps and byte-level challenges. Base64 is denser (about 133% of the original) and is the default for embedding binary in text. URL encoding is different in kind: it leaves safe characters alone and replaces only unsafe ones with %XX, so it appears in web requests, query strings and logs rather than as a general binary wrapper.

A quick way to tell them apart by eye: only 0–9 and a–f in pairs means hex; a mix of upper case, lower case and digits ending in = means Base64; percent signs mean URL encoding. Some strings fit more than one format, such as deadbeef, which is valid hex and valid Base64 — in that case the tool follows both and ranks the results rather than guessing.

Paste the hex into the input box — plain pairs (68656c6c6f), spaced pairs (68 65 6c 6c 6f), 0x-prefixed bytes or colon-separated bytes all work. The detector picks it up automatically; if it does not, choose Base16 / Hex in the format picker. If the digit count is odd the last digit is dropped and the layer shows a warning, so you know a byte was incomplete rather than having it silently changed.

Each pair of digits becomes one byte, so 68 65 6c 6c 6f becomes h, e, l, l, o. If the bytes are not readable text — for example, a 32-digit string that is really an MD5 hash — the layer says so and shows a hex dump instead of printing garbage, and it points you to the Hex Viewer when you want to look at the raw bytes.

A typical beginner challenge hides a flag under two or three layers of encoding. Say the string is NjY2YzYxNjc3YjY4Njk3ZA==: the tool sees a length divisible by 4, a trailing = and a mixed-case alphabet, scores Base64 at the top, decodes it, and finds 666c61677b68697d — a run of hex digits in pairs. The hex layer decodes to flag{hi}, the flag pattern appears, and the chain stops there with the whole path shown.

If the hex had been ROT13-shifted first, you would see a third layer. Because every layer shows its entropy, printable share and the reasons behind its format, you can check each step instead of trusting the final answer. When the flag format is not flag{...}, add your event's prefix once in Advanced options and it is highlighted at every layer from then on.

Look at the shape before you decode: a long string ending in = is almost certainly Base64; only 0–9 and a–f in pairs is hex; %XX means a URL; dots, dashes and slashes mean Morse. Add your event's flag prefix (THM, CTF-, …) so highlighting works at every layer, not only the last one.

If a decode produces gibberish, check the other paths before assuming you chose wrong — the same string can be valid in two formats. If the output stays high-entropy and unreadable, it is probably encrypted, compressed or XOR'd rather than encoded; the quick XOR check tries all 255 single-byte keys on the first 4 KB. Pasted a whole log or email instead of a clean string? Use the embedded-blob finder to locate the encoded runs inside it.