Binary to Text Converter
Paste binary in whatever shape it actually arrived in — no spaces, extra dashes, uneven groups — and get readable text back instantly. Handles UTF-8 and emoji correctly, and converts the other way too.
How to Decode (or Create) Binary
Features
Received a Wall of 0s and 1s? Here's What to Do
Whether it arrived as a CTF challenge, a steganography extraction, a network packet dump, or a homework problem, a binary-encoded string is meant to follow a simple pattern: groups of exactly 8 digits using only 0 and 1, typically separated by spaces. In practice, it almost never arrives that cleanly — spaces go missing when text gets copy-pasted through a chat app, separators get swapped for dashes or commas depending on who generated it, and stray groups end up a bit short or a bit long. Most converters simply fail the moment any of that happens. This one doesn't: paste it as-is, and the decoder cleans up the formatting automatically before doing the actual conversion, using the same native TextDecoder your browser relies on for every UTF-8 web page it renders — which is exactly why emoji, accented letters and other multi-byte characters come through correctly rather than as scrambled symbols.
From Eight Bits to One Character — the Actual Math
Each 8-bit group represents a single byte, a value between 0 and 255. Reading the group as a binary number means multiplying each digit by its positional value — 128, 64, 32, 16, 8, 4, 2, 1, left to right — and adding the results together. 01001000 works out to 0+64+0+0+8+0+0+0 = 72, and looking 72 up in the ASCII table gives you the letter "H." The tool performs this arithmetic for every group in your input, assembles the resulting byte values into an array, and hands that array to TextDecoder, which reconstructs multi-byte UTF-8 sequences automatically — a byte starting with the bit pattern 11110 signals the start of a 4-byte sequence (the range most emoji live in), with the following three bytes each starting 10 as continuation bytes.
The Three Formatting Problems Lenient Parsing Actually Solves
The single most common issue is binary with no spaces at all. A continuous run like 0100100001101001 is genuinely ambiguous on its own — split at the wrong point and you get a completely different result — so this tool automatically chunks an unspaced run into 8-bit groups starting from the left, which is the correct interpretation for the overwhelming majority of real-world binary text. The second is mixed or unusual separators — some sources use dashes, underscores or commas instead of spaces, and Lenient Parsing treats all of them the same way. The third is groups that are the wrong length — a group that's short gets padded with leading zeros to reach 8 bits, and a group that's too long gets re-split into proper byte-sized chunks, rather than the whole conversion failing over one malformed group in the middle of a long string.
If you'd rather see exactly where a real problem is instead of having it silently patched over, turn Lenient Parsing off — strict mode then reports precisely which group failed and why, which is often more useful when you're debugging your own encoder's output than when you're just trying to read someone else's message.
Where This Actually Comes Up
- CTF flag extraction — competition challenges frequently hide the flag as a binary string; pasting it here reveals it immediately, no manual arithmetic required
- Steganography recovery — bits extracted from the least significant bits of image pixels come out as a binary string that needs converting back to the hidden message
- Protocol and packet analysis — tools like Wireshark sometimes display field values in binary that need decoding to understand the human-readable content
- Checking your own encoder — build a text-to-binary encoder and run its output back through this decoder to confirm it round-trips correctly
- Coursework and self-study — decode a string by hand as a learning exercise, then check your work against the tool's result instantly
Decoding Is Not the Same Thing as Decrypting
Binary is simply a different representation of the exact same information — reversing it back to text needs no key, no password, nothing kept secret, because nothing about the encoding itself ever was. Encryption is a different problem entirely: it deliberately requires a key that only an authorized party holds. If what you're decoding here turns out to be ciphertext rather than plain readable text, decoding the binary only gets you back to the encrypted bytes — the next step would be AES decryption with the correct key, not another round of binary conversion.
Tips for Clean Results
- Leave Lenient Parsing on by default. It handles the formatting quirks that trip up most binary you'll actually encounter, and only strict mode's precise errors are worth the extra friction when you're specifically debugging your own code.
- Garbled output almost always means a shifted byte boundary, not a broken tool. If a long string decodes to nonsense, check whether a single character got dropped somewhere near the start — everything downstream shifts once that happens.
- Use the ASCII table to sanity-check one character at a time rather than guessing at the arithmetic by hand.
- Reach for Text to Binary instead if you need hexadecimal, octal or decimal output alongside binary — this tool stays deliberately binary-only in both directions.
When This Isn't the Right Tool
If you need binary alongside hex, octal or decimal representations in the same place, use Text to Binary instead, which covers all four number bases. If what you're actually trying to reverse is a Caesar shift or ROT13, not a byte encoding, see the Caesar Cipher or ROT13 tools. And if the data you're working with is genuinely encrypted rather than merely encoded, no amount of binary decoding will recover it — you need the correct key and the AES Encryption tool's decrypt mode instead.