Text to Binary Converter

About the Text to Binary Converter

This text to binary converter turns any string into its underlying byte values written in base 2, 8, 10 or 16, and converts those values back into readable text. Encoding runs the text through UTF-8 first, so what you see is the true byte sequence a computer would store or transmit, not a simplistic one-number-per-letter mapping. Binary output is padded to eight digits per byte, hexadecimal to two and octal to three, giving neatly aligned columns. A details panel reports the character count against the byte count, which is where UTF-8 becomes visible.

How to use the Text to Binary Converter

1. 1

   Enter your text, or a list of numeric byte values, in the 'Input' box.

2. 2

   Set 'Action' to 'Text → code' to encode, or 'Code → text' to decode.

3. 3

   Choose a 'Number base': Binary, Octal, Decimal or Hexadecimal.

4. 4

   When decoding, separate each byte with a space or a comma — leading zeros are optional.

5. 5

   Copy the encoded output, or read the decoded text in the panel below.

What people use it for

Why UTF-8 makes character and byte counts diverge

UTF-8 is a variable-length encoding, and it is the reason the Details panel reports characters and bytes separately. Any character in the ASCII range, code points 0 to 127, encodes to exactly one byte whose top bit is zero, which is what makes UTF-8 backwards compatible with ASCII: the binary for a plain capital H is 01001000 under both. Characters from 128 to 2047, which covers accented Latin letters, Greek and Cyrillic, take two bytes. Most of the remaining Basic Multilingual Plane, including Chinese, Japanese and Korean ideographs, takes three. Everything above that, notably emoji, takes four. The structure is self-describing: a leading byte announces the length of the sequence through the number of high bits set before the first zero — 110xxxxx for two bytes, 1110xxxx for three, 11110xxx for four — and every continuation byte begins 10. That design means a decoder can resynchronise after a corrupted byte, and it is why a single emoji produces four groups of eight binary digits rather than one. Encoding a mixed string and comparing the two counts shows exactly how much of your text is outside ASCII.

Padding, separators and what the decoder accepts

When encoding, each byte is padded so that the columns line up: eight digits in binary, three in octal and two in hexadecimal, while decimal is left unpadded because leading zeros there look like a formatting error rather than a convention. Bytes are joined with a single space. The decoder is more permissive than the encoder: it splits on any run of whitespace or commas, so it accepts space-separated, comma-separated, newline-separated and mixed input, and leading zeros are optional throughout. Every token must be a valid byte for the chosen base, meaning a value from 0 to 255; anything that fails to parse or falls outside that range is reported by name so you can find it, rather than being quietly dropped. Two mistakes account for most decoding failures. The first is choosing the wrong base — a string of 0s and 1s parses perfectly well as decimal and produces nonsense. The second is pasting binary with no separators at all, which the decoder cannot split reliably, since it has no way to know whether an unbroken run of digits is meant to be read in groups of eight. Insert spaces every eight digits first.