How Text Becomes Binary

Computers only store two things: 0 and 1. So how does a message like “Hi” — or a Bengali sentence, or an emoji — end up inside one? The answer is a chain of agreements, each simple on its own, and together they are the reason text works at all across billions of devices that have never met.

Step 1: characters become numbers

A computer cannot store a letter. It can store a number. So the first agreement is a table mapping every character to a number.

That table is ASCII, agreed in the 1960s:

• A = 65, B = 66 … Z = 90
• a = 97, b = 98 … z = 122
• 0 = 48 … 9 = 57
• space = 32

Two quiet elegances hide in there. First, uppercase and lowercase differ by exactly 32 — which in binary means flipping a single bit. Changing case is one of the cheapest operations a computer can perform.

Second, the digits are in order starting at 48, so converting the character 7 to the number 7 is just subtracting 48.

Step 2: numbers become binary

Now write each number in base 2, padded to eight digits — one byte.

H is 72. In binary: 01001000.
i is 105. In binary: 01101001.

So “Hi” is 01001000 01101001. That is the whole trick. Text is a list of numbers, and numbers are bits.

Why eight bits?

A byte is eight bits, which can hold 256 distinct values (0–255). ASCII only needed 128, so seven bits would have sufficed — but eight is a power of two, convenient for hardware to address, and it left a spare bit.

The byte then became the fundamental unit of computing. It is why storage is measured in bytes, why colour channels run 0–255, and why so many limits in computing are suspiciously close to 256.

The problem: 128 characters is not enough

ASCII was designed by and for English speakers. It has no é, no ñ, no Bengali, no Chinese, no Arabic — and certainly no emoji.

For decades the workaround was a mess of competing code pages: regional tables that each assigned different characters to the values 128–255. Byte 233 meant é in one encoding and something entirely different in another.

The consequence was mojibake — the garbled text everyone has seen, where café arrives as café. Nothing was corrupted; the receiving program simply used a different table than the sending one. The bytes were fine. The agreement had failed.

The solution: Unicode and UTF-8

Unicode fixed the first half of the problem by giving every character in every writing system a unique number — over 150,000 of them, covering every living language, historical scripts, mathematical symbols and emoji. The letter A is still 65; a Bengali অ is 2437; 😀 is 128512.

But that creates a new question: some of those numbers are large, so how do you store them without making every character four bytes and quadrupling the size of all English text on earth?

UTF-8 is the answer, and it is genuinely one of the most elegant designs in computing. It is variable-width:

• 1 byte for the original ASCII characters (values 0–127).
• 2 bytes for most European and Middle Eastern scripts.
• 3 bytes for most Asian scripts, including Bengali and Chinese.
• 4 bytes for emoji and rarer symbols.

The masterstroke: UTF-8 is backwards-compatible with ASCII. An English document is byte-for-byte identical in both, so every ASCII file ever written was already valid UTF-8 the day the standard appeared. You pay for the extra characters only when you use them.

This is why UTF-8 won so completely — it now encodes the overwhelming majority of the web — while alternatives that made English text bigger did not.

Why an emoji is not one character

A consequence worth knowing, because it breaks a lot of code. In UTF-8, an emoji takes four bytes. And many emoji are worse: 👨‍👩‍👧‍👦 (family) is actually several emoji joined by invisible connector characters, and can run to 25 bytes or more.

This is why a “280 character” limit sometimes behaves strangely, why naive code splits an emoji into garbage halfway through, and why counting the length of a string is far less obvious than it looks. A skin-tone modifier is a separate code point layered onto the base emoji.

Decoding, and how to spot problems

Going back to text simply reverses the steps: split into bytes, work out how many bytes each character uses, convert to a number, look it up. What matters is that both sides agree on the encoding.

Two symptoms tell you what went wrong:

• café — UTF-8 bytes are being read as if they were single-byte code page characters. The classic case.
• caf� — the replacement character, meaning the bytes were not valid UTF-8 at all.

The fix is always the same: declare UTF-8 explicitly, everywhere — in your HTML, your database, your file reads, your HTTP headers. Never let anything guess.

Frequently asked questions

What is the binary for a space? Character 32, which is 00100000.

Why is every character eight bits? Only ASCII characters are. In UTF-8, other characters use two, three or four bytes.

Is ASCII still used? Yes — it is a subset of UTF-8, so ASCII text is automatically valid UTF-8.

Why do I see weird characters instead of accents? An encoding mismatch. Something is reading UTF-8 bytes with the wrong table.

Convert text to binary now

Use our Text to Binary converter to encode any message into 8-bit binary and decode it back — it uses UTF-8, so emoji and non-English scripts work correctly. To explore the number systems underneath, try the Number Base Converter, and for a different way of encoding data as text, read what Base64 encoding is.