How the decoder reads your input
Decoding is three steps: split the input into byte values, check each value, then interpret the bytes as UTF-8 text. The sample 01001000 01101001 00100001 becomes the bytes 72, 105 and 33, which are H, i and an exclamation mark. Nothing is guessed. If the input cannot be split cleanly into bytes, you get an error and no partial text.
Each format has its own splitting rule. Hex ignores 0x prefixes, spaces, commas, colons, semicolons, pipes, underscores and hyphens, then reads the digits two at a time, so 48:69:21, 0x48 0x69 0x21 and 486921 all decode to the same three bytes. Decimal and octal have no fixed width here, so the values must be separated by spaces, commas, semicolons, pipes or line breaks: 72 105 33 in decimal, 110 151 041 in octal.
Decoding binary by hand
Each position in a byte is worth a power of two: 128, 64, 32, 16, 8, 4, 2 and 1 from left to right. Add the values where a 1 appears. For 01001000 that is 64 + 8 = 72, and 72 in the ASCII table is the capital H. For 01101001 it is 64 + 32 + 8 + 1 = 105, the lower-case i.
A few landmarks make this quicker. Bytes beginning 010 are mostly capital letters and those beginning 011 mostly lower-case letters. The digits 0 to 9 begin with 0011, and their last four bits are the digit itself. 00100000 is a space. A byte beginning with 1 is not ASCII at all: it belongs to a multi-byte UTF-8 character and has to be read together with its neighbours.
Why the output looks wrong
Nonsense output with no warning usually means the digits were grouped wrongly at the source. If one bit was lost in copying, every byte after it is misaligned, and the decoder either reports a bad bit count or produces garbage. Count the digits: the total must divide by eight.
The not valid UTF-8 note points to a different cause: the bytes are in another encoding. In Windows-1252 and Latin-1 the single byte E9 is the letter e with an acute accent, but UTF-8 writes that letter as C3 A9, so E9 on its own is flagged. UTF-16 is a separate case: it decodes without a warning, but every other byte is 00, as in 48 00 69 00, which leaves invisible null characters between the letters. Compressed files, images and encrypted data are not text in any encoding.
- An odd number of hex digits: one was dropped, since hex must come in pairs.
- A decimal value above 255: the numbers are code points or 16-bit units, not bytes.
- Binary groups of seven digits: 7-bit ASCII, which needs a leading 0 added to each group.
What the decoder will not do
The decoder knows one text encoding, UTF-8, which also covers plain ASCII. It does not offer Latin-1, Windows-1252, UTF-16 or EBCDIC, does not detect the encoding for you, and does not decode Base64, which is a different scheme altogether. Use Base64 Encoder / Decoder for strings made of letters, digits, plus and slash. Dots and dashes are Morse, which Morse Code Translator handles.
Everything is computed in the page, so pasted data does not leave your browser. Swap direction takes the decoded text and encodes it again in the Text to Binary Converter direction, a quick way to tidy the spacing or turn a binary string into hex. Control characters decode to themselves and may be invisible in the output box even though the byte count includes them.