Binary Translator

How text becomes binary

A computer stores text as numbers, and stores numbers as bits. Turning text into binary is therefore two steps: each character is first given a number, and that number is then written out as bytes of eight bits each.

Take the word Hi. The capital H is number 72 and the lower-case i is 105. Written in base 2, 72 is 1001000 and 105 is 1101001. Each is padded to a full byte, so the result is 01001000 01101001 — sixteen bits for two characters. That eight-bit grouping is why binary text always comes in blocks of eight digits.

The numbers for the basic Latin letters, digits and punctuation come from ASCII, a 1963 standard that assigned 128 codes. Those same 128 values survive unchanged inside Unicode and UTF-8, which is why an English sentence produces identical binary whichever of them a tool claims to use.

Why é is two bytes and an emoji is four

ASCII stops at 127, so it has no é, no ₹, no Chinese characters and no emoji. Unicode gives every character in every script a code point — é is U+00E9, the rupee sign is U+20B9, and 😀 is U+1F600 — and UTF-8 is the rule for storing those code points as bytes.

UTF-8 uses one byte for ASCII and two, three or four bytes for everything else. The leading bits of each byte say how long the sequence is: a byte starting 110 opens a two-byte character, 1110 a three-byte one, 11110 a four-byte one, and every continuation byte starts 10. So é becomes 11000011 10101001 (C3 A9 in hex), the euro sign € becomes three bytes, E2 82 AC, and 😀 becomes four, F0 9F 98 80.

This is why binary translators disagree. One that treats each character as a single byte either mangles é or silently drops it, and one that uses UTF-16 — the encoding JavaScript and Windows use internally — produces 16-bit groups instead of 8. This tool uses UTF-8 throughout because it is what web pages, JSON, source code and almost every text file on disk are actually stored in, so its output matches what a program reading the file would see.

Reading binary back into text

The decoder is deliberately forgiving about layout. Bytes can be separated by spaces, commas, semicolons or new lines, or run together with no separators at all, and they may carry a 0b prefix. A long unbroken run is cut every eight digits, which only works if its length is a multiple of eight — if it is not, a digit is missing or extra, and the error says so rather than guessing which.

Groups of seven bits are read as 7-bit ASCII with a leading zero, because older textbooks and puzzles often write characters that way. A group of nine or more bits that does not split evenly into bytes, or any digit other than 0 or 1, is reported along with which group it was in — on a 400-digit message, "invalid input" alone is not something anyone can fix.

Bytes that are not valid UTF-8 — a multi-byte character cut short, or a stray continuation byte — are flagged with a warning. The readable part is still shown, with the replacement character � standing in for whatever could not be decoded, so one damaged byte does not hide the rest of the message.

Hex, octal, decimal and code points

Binary is the honest view of the bits, but it is long. Hexadecimal writes each byte as exactly two digits from 0–9 and A–F, so H is 48 and i is 69. Programmers read hex for that reason: the byte boundaries are visible and the text is a quarter of the length. It is also the form that appears in URL escapes (%48), in C and Python string escapes (\x48) and in hex editors.

Octal writes each byte as three digits from 0 to 7 — H is 110 — and survives mainly in older escape sequences and in Unix file permissions. Decimal bytes are each byte as an ordinary number from 0 to 255, the form you would get by reading a file into an array in most languages. Because decimal has no fixed width, it always needs separators.

Code points are different in kind: they describe the character, not its bytes. One code point can be up to four UTF-8 bytes, so 😀 is a single code point, U+1F600, but four bytes. When you need to look a character up in the Unicode charts or type it with an escape like \u{1F600}, the code point is the number you want.

Decoding binary by hand

For plain English text there is a shortcut worth knowing. Capital letters all start 010 and lower-case letters all start 011; the remaining five bits give the letter's position in the alphabet. So 01000001 is capital A (position 1), 01100001 is lower-case a, and 01011010 is Z (position 26). The digits 0–9 all start 0011, followed by the digit itself in four bits — 00110111 is the character 7.

A space is 00100000 — a lone 1 in the third place — which makes word breaks easy to spot in a long message. With those three patterns you can read most short binary messages without a table, and check the output of any translator, including this one.