Binary to Text Converter

Paste a bit string and watch it turn into readable text as you type. Pick UTF-8, ASCII or Latin-1, drop to 7-bit groups for older captures, then open the byte inspector to see which bytes produced which character.

Binary decoder workbench

Character set
Bits per group

Binary

Spaces, commas and line breaks are skipped
0 bits0 bytesWaiting for input

Decoded text

Decoded characters appear here as you type.
0 characters

Byte inspector

Every decoded character lands here with the exact bytes behind it.

How a binary string turns back into readable text

Every string a computer holds is a run of numbered bytes. Decoding reverses the trip: split the bit stream into groups of eight, read each group as a number between 0 and 255, then look up the character sitting at that number. The dark panel holds the machine side of the conversation. The light panel holds yours.

Eight bits per character, with one older exception

Byte-aligned text spends eight bits per character, so 96 bits carry 12 characters. The 7-bit setting exists for older material. Serial captures, teletype archives and some SMS payloads packed characters into seven bits to save line time, so an 8-bit split turns them into garbage. If the output looks like noise but the source is genuinely old, switch the width to 7 before writing off the data.

Where ASCII stops and UTF-8 keeps going

ASCII covers the first 128 values: English letters, digits, punctuation, plus 33 control codes. Anything above 127 sits outside the standard, which is why the ASCII setting flags those bytes rather than guessing at them.

UTF-8 reaches the rest of Unicode by spending extra bytes on higher code points. The lead byte announces the length through its top bits, so a decoder knows how far to read before any lookup happens. A byte starting 0 stands alone, 110 opens a two-byte run, 1110 opens three, 11110 opens four. Continuation bytes always start 10, which is what makes a broken sequence easy to spot.

CharacterCode pointUTF-8 bytesBinary
AU+00414101000001
éU+00E9C3 A911000011 10101001
U+2615E2 98 9511100010 10011000 10010101
😀U+1F600F0 9F 98 8011110000 10011111 10011000 10000000

Reading the byte inspector

Each card in the inspector is one decoded character alongside the raw bytes behind it: the binary group, the decimal value, the hex value and the Unicode code point. Multi-byte characters keep their bytes together on a single card, so a two-byte é reads as one unit instead of two mystery numbers. Control codes get a name label such as LF, TAB or NUL, because a blank card tells you nothing. Bytes with no valid mapping turn red, which points at the exact spot where a paste went wrong.

Where binary text shows up in real work

  • Protocol documentation printing a payload as bits rather than hex
  • Capture-the-flag puzzles hiding a flag inside a long bit string
  • Serial or UART logs read off a board before anyone has written a parser
  • Coursework on character encoding, where seeing the bits matters more than the answer
  • A raw dump pasted into a bug report by someone who never decoded it

What usually goes wrong

  • The bit count is not divisible by eight. Complete groups still decode, leftover bits get reported under the input. A count of 3 or 5 trailing bits almost always means the copy stopped short.
  • The bit order is reversed. Some hardware dumps arrive least significant bit first, so every byte decodes to a plausible but wrong character. Reverse each group of eight before pasting.
  • The source was never text. Compressed, encrypted or binary-format payloads produce noise under every setting, no matter which character set is picked.
  • Control bytes render as nothing. The output looks shorter than the byte count suggests. The inspector shows those bytes by name, so the gap stops being a mystery.

Limits worth knowing

Decoding runs in your browser with no upload step, so payloads from private captures stay on your machine. Two limits are worth stating plainly. UTF-16 and UTF-32 input sit outside scope, since both need byte-order handling this decoder does not attempt. Reversed bit order goes undetected, because a reversed byte string is valid binary and nothing in the data announces the mistake. The inspector also renders in batches of 160 characters to keep large pastes responsive, while the text output stays complete.

Pair this with related converters

Going the other direction is a job for the String to Binary Converter. For bit strings you would rather read as numbers, the All Number Converter moves between binary, decimal, hexadecimal and octal in one pass, while Binary to Hex gives you the compact form most tooling prefers. When the dump arrived as hex instead of bits, start at the Hex to String Converter, and for a payload wrapped in Base64, run it through the Base64 Decoder first.

Binary to Text Converter FAQ

Practical answers to the questions that come up most while decoding bit strings.

How do I convert binary to text?

Paste the bit string into the left panel. Decoding runs as you type, so no button press is needed. Keep the default 8-bit width unless the source is an old 7-bit capture, and keep UTF-8 selected unless you know the data predates it.

Does the converter accept binary without spaces?

Yes. Spaces, line breaks, commas, dashes and underscores are treated as separators. A run of 96 unbroken digits decodes exactly like 12 spaced groups. Anything other than a 0 or a 1 gets counted as stray input and reported under the panel instead of silently changing the result.

What happens when the bit count is not a multiple of eight?

Complete groups decode normally and the leftover bits are reported rather than dropped without notice. Seeing 3 trailing bits usually means the copy stopped short, so check the end of the source before trusting the last character.

Which character set should I pick?

UTF-8 handles everything modern, including accents, symbols and emoji, and is the right default. ASCII covers the first 128 values only and flags any byte above 127 instead of guessing. Latin-1 maps all 256 byte values to characters, which helps with older Western European files.

Why does my binary decode into random symbols?

Three usual causes. The bit order arrived least significant bit first, the group width should be 7 rather than 8, or the source was never text at all. Compressed and encrypted payloads produce noise under every setting.

Is my data sent to a server?

No. Decoding happens entirely in your browser with no upload step, so binary pulled from private captures or client systems stays on your machine.