Why your binary-to-text conversion outputs the wrong characters

A string of 1s and 0s looks unambiguous — it’s binary, there’s nothing to interpret. In practice, converting binary to text fails in exactly the same family of ways hex-to-text does, for the same underlying reason: a sequence of bits isn’t text until you’ve made several assumptions about how to group and interpret it, and getting any one of those assumptions wrong produces output that’s wrong in a specific, diagnosable way.

Cause 1: wrong bit-grouping (7-bit vs. 8-bit)

Standard ASCII only needs 7 bits per character; most binary-to-text tools default to 8-bit bytes because that’s how text is actually stored on real systems. If a binary string was generated assuming 7-bit groupings (some textbook examples and older systems still do this) and you decode it as 8-bit bytes, every single character comes out shifted — the grouping boundary is wrong from the very first bit, so the corruption is uniform across the entire output rather than starting clean and degrading partway through.

The tell: if literally every character in the output is wrong, not just some, check the bit-grouping assumption before anything else.

Cause 2: an extra or missing bit shifts everything after it

This is the binary equivalent of an odd hex digit — a single stray 0 or 1 (an extra character from a copy-paste, a dropped digit, whitespace that got parsed as data) shifts the byte boundary for every group after that point. Unlike cause 1, this produces text that’s correct up to a point and garbled afterward — a strong signal that the bit count itself is off somewhere in the string rather than the encoding scheme being wrong throughout.

Count the total bits first: the string length should be a clean multiple of 8 (or 7, if you’ve confirmed that’s the grouping in use). If it isn’t, the extra or missing bit is the bug, not the decoder.

Cause 3: character encoding, exactly as with hex

Once the bits are correctly grouped into bytes, you still have to decide what those byte values mean as characters — UTF-8, ASCII, Latin-1. This is identical to the hex-to-text case: multi-byte UTF-8 characters (accented letters, symbols, non-Latin scripts) decoded one byte at a time as if each byte were its own character produce two or three garbled symbols in place of one correct one. If the bit-grouping is confirmed correct (cause 1 and 2 ruled out) and the output is still wrong specifically around non-ASCII characters, this is almost always the remaining cause.

Cause 4: endianness, for binary representing numbers rather than text

If the binary string encodes a numeric value rather than character data — a length prefix, a checksum, an ID embedded alongside text — bit/byte order matters and there is no universal default. 00000001 as a standalone byte is unambiguous, but multi-byte numeric values can be stored most-significant-byte-first or least-significant-byte-first depending on the system that produced them, and reading it with the wrong assumption silently produces a different, plausible-looking wrong number rather than an obvious error.

Diagnosing in order

1. Check total bit count is a clean multiple of your assumed grouping (8, usually) — an off count means cause 2, fix the input.
2. If every character is wrong uniformly from the start, suspect the grouping size itself (cause 1) before touching the encoding.
3. If output is clean at first and degrades partway through, that pinpoints a stray/missing bit at that position (cause 2), not an encoding problem.
4. If grouping and bit-count both check out and only non-ASCII characters look wrong, it’s character encoding (cause 3).
5. If the data represents a number rather than text and the value looks plausible but wrong, check byte order (cause 4) before assuming the conversion logic itself is broken.

As with hex, the conversion step is trivial — the actual bug almost always lives in one of these four assumptions, not in the code doing the converting.