A string like 01001000 01101001 looks like it should be self-explanatory, but nothing about those digits says "letters" on its own. Binary is just base-2 numbers. Turning it into text takes two separate agreements: where one character's digits stop and the next one's start, and which number stands for which letter. Both of those are conventions, not properties of the 1s and 0s themselves, which is also exactly where a binary-to-text conversion goes wrong.
A byte is a number before it's a letter
Eight binary digits, a byte, can represent any whole number from 0 to 255, the same way eight decimal digits represent a bigger range of numbers in base 10. 01001000 is the number 64 + 8 = 72 in binary, nothing more. It only becomes the letter "H" because of a lookup table: ASCII, the standard that says "72 means H", "73 means I", and so on for the 128 numbers from 0 to 127. Without agreeing on that table first, 72 is just 72. Docexp's converter does this lookup for you, split the input into bytes, read each one as a number, and hand that number to the browser's built-in decoder, which knows the table.
Why the bytes have to be split correctly before decoding
A decoder has to know where one 8-digit group ends and the next begins. Run several characters together with no separator, 0100100001101001 for "Hi", and a program has no way to tell whether that's two 8-bit bytes or one 16-bit number, unless it's told the rule in advance. That's why Docexp's converter outputs space-separated groups rather than one long digit string, and why the decoder expects spaces back: the space is the boundary information, not decoration.
This is also where a sloppier converter does real damage rather than just failing cleanly. Each space-separated chunk gets read as one number and then forced into a single byte (0 to 255). A chunk that isn't exactly 8 digits still parses. It's still a valid number, but if it's longer than 8 bits, the extra value gets silently discarded rather than flagged as wrong, and the decoded character comes out as noise instead of a clear error. The safe rule when typing or pasting binary by hand: every group between spaces should be exactly 8 digits, no more, no fewer. A 7-digit group because you dropped a leading zero is the single most common reason a decode comes out garbled rather than simply failing.
ASCII stops at 127, which is where most "garbled text" complaints start
ASCII only defines 128 numbers (0 to 127), which covers the English alphabet, digits and basic punctuation, enough for the character set it was designed around in the 1960s, and nothing with an accent, a rupee sign, or an emoji. Modern text is almost never pure ASCII; it's Unicode, usually stored as UTF-8, which keeps ASCII's first 128 characters identical but represents everything else using more than one byte per character. An emoji or a letter with an accent might take two, three or four bytes rather than one.
This matters for decoding because a single byte on its own, read in isolation, can't tell you it's "part two of three" for some character outside ASCII, the decoder needs all of that character's bytes, in order, to resolve correctly. Docexp's converter decodes using UTF-8 rules rather than assuming one byte always equals one visible character, so a binary string for "café" or "🎉" round-trips correctly as long as every byte for that character made it into the input. Drop or reorder even one byte of a multi-byte character, though, and the decoder has no way to recover. You get the standard replacement character (�) rather than the letter you expected, because the bytes it has no longer describe anything valid.
A worked example
Decoding 01001000 01101001 by hand: 01001000 is 64 + 8 = 72, which ASCII maps to "H". 01101001 is 64 + 32 + 8 + 1 = 105, which maps to "i". Put them together and the binary says "Hi", the same answer the converter gives right away, just worked out one lookup at a time instead of 128 at once.
Going the other way: text to binary
Converting text to binary runs the same process in reverse: each character becomes a number (its ASCII or Unicode code point), and each number becomes an 8-digit binary group, space-separated. The only part people don't expect: a single visible character outside the original ASCII range doesn't always produce one 8-digit group. An emoji, for instance, is stored as several bytes in UTF-8, so it comes out as several 8-digit groups for what looks on screen like one character, which is correct, not a bug, and is the same multi-byte reality that makes decoding emoji from binary need every one of those groups present.
What this is actually used for
Mostly three things: checking a homework or coursework answer for a class covering number systems or character encoding, decoding a short string handed over in a puzzle or a CTF challenge where "binary" is the obvious first format to try, and making sense of a raw byte dump from a serial port, firmware log, or low-level debugging tool where the data is already sitting in front of you as 1s and 0s and the question is simply "what does this say."
Frequently asked questions
Why did my binary-to-text conversion come out as garbled symbols instead of real letters? Almost always a byte-grouping problem: a missing leading zero, an extra digit, or bytes pasted without the spaces that mark where one character ends and the next begins. Each group between spaces needs to be exactly 8 digits. If the text uses accents, emoji or any non-English character, a dropped or reordered byte from a multi-byte UTF-8 sequence will also show up as a garbled or replacement character rather than the intended one.
What's the difference between binary-to-text and Base64? Base64 encodes any bytes, image data, a file, encrypted output, not just text, into a 64-character alphabet (A to Z, a to z, 0 to 9, +, /) so they survive being copied through systems that only handle plain text safely. Binary-to-text, by contrast, assumes the bytes you're decoding were already meant to be read as character codes under ASCII or Unicode. Feeding Base64 output into a binary-to-text decoder, or the reverse, produces nonsense, because the two are solving different problems.
Can binary represent emoji or non-English text? Yes, through UTF-8, which represents any Unicode character as one to four bytes. The catch is that decoding needs every byte of that character, in the right order; a partial or reordered sequence can't be resolved and shows up as a replacement character instead of the one intended.
Does the spacing in a binary string actually matter? Yes. The spaces aren't formatting, they're the only thing telling a decoder where one 8-bit byte stops and the next starts. Run the digits together with no separator, or drop a digit so a group isn't exactly 8 bits, and the byte boundaries shift for every character after the mistake, not just the one it happened in.
Both converters run entirely in your browser. Nothing you type or paste is uploaded anywhere.