How Text Becomes Binary: Code Points, ASCII, and 8-Bit Bytes Explained

A computer never stores the letter "A". It stores a number, and that number is written as a row of ones and zeros. Everything you see on screen — this sentence, your name, an emoji — is a pile of bits that some program agreed to draw as glyphs. Once you can do the conversion by hand for a few characters, the whole stack of "encoding" jargon stops being scary and turns into simple arithmetic.

This post walks the full path: a character becomes a code point, the code point becomes a byte (or a few bytes), and the byte gets written as 8 bits. Then we run it backward to decode. You can follow along in the Text to Binary converter and watch every step happen live.

Step one: a character is really a number

Text starts as a list of characters, but a computer can only count. So before anything else, each character is mapped to a number called a code point. The mapping is fixed by a standard called Unicode, and for the English letters and punctuation you type every day it lines up with the old ASCII table.

Here is the concrete rule that does most of the work: each character maps to a code point, and for the basic Latin range that code point fits in 8 bits. The capital letter A has code point 65. Write 65 in binary and you get 01000001. That is the entire trick for English text — look up the number, write it in base 2, pad to 8 digits.

A few more, so the pattern sinks in:

• H is code point 72 → 01001000
• i is code point 105 → 01101001
• space is code point 32 → 00100000
• 0 (the digit zero) is code point 48 → 00110000

Notice that lowercase i (105) is bigger than uppercase A (65). The uppercase letters live in the 65–90 block and the lowercase ones in the 97–122 block, exactly 32 apart. That 32 gap is why flipping one bit can change case — but that is a story for another day. If you want the full lookup table, the ASCII Table Reference lists every code point from 0 to 127 with its binary form.

Step two: a code point becomes a byte

A byte is 8 bits. Eight bits can hold 2^8 = 256 distinct values, the numbers 0 through 255. The original ASCII range only uses 0 through 127, which means the top bit is always 0 for plain English text. That is why every ASCII character above turns into a binary string that starts with a zero.

When I first wired up a tiny serial display project years ago, this was the moment it clicked for me. I was sending the string "OK" down a wire one bit at a time, and the only way to debug it was to count pulses on an oscilloscope. O was 01001111, K was 01001011. Seeing those exact patterns scroll past on the screen, matching the numbers I had computed on paper, made the abstraction feel physical. The text wasn't "in" the wire — the wire just carried 16 voltage flips, and both ends had agreed what they meant.

The agreement is the whole point. An encoding is a contract: "I will write code point 72 as these 8 bits, and you will read these 8 bits back as 72." Break the contract on either side and you get garbage. That is most of what "encoding bugs" actually are.

A worked example: "Hi" in binary

Let's do a full conversion end to end. Take the two-character string Hi.

1. Split into characters: H, i.
2. Map each to a code point: H → 72, i → 105.
3. Convert each number to binary and pad to 8 bits:

• 72 = 64 + 8 = 01001000
• 105 = 64 + 32 + 8 + 1 = 01101001

1. Join the bytes: 01001000 01101001

That space in the middle is just for human eyes — it marks the boundary between the two bytes. The computer stores 16 bits with no gaps. Paste Hi into the Text to Binary converter with 8-bit grouping on and you get exactly 01001000 01101001 back. The math you did by hand and the browser's built-in encoder agree to the last bit.

To prove you understand it, try the addition yourself. For 72: the place values from left to right are 128, 64, 32, 16, 8, 4, 2, 1. You need 64 and 8, so put a 1 under those two columns and a 0 everywhere else: 0 1 0 0 1 0 0 0. Done.

Going beyond English: when one character needs more bytes

English is the easy case because every letter fits in one byte. The moment you type Chinese, Japanese, Arabic, or an emoji, the code points run past 127 and one byte is no longer enough. This is where UTF-8 earns its keep.

UTF-8 is a variable-length encoding. Code points 0–127 stay one byte (so all your ASCII work above is still valid). Code points from 128 up spill into 2, 3, or 4 bytes, using a clever marker scheme where continuation bytes always start with 10. A few real examples:

• é (code point 233) → 2 bytes
• 李 (code point 0x674E = 26446) → 3 bytes → 11100110 10011101 10001110
• 🎉 (code point 0x1F389) → 4 bytes → 11110000 10011111 10001110 10001001

So "one character" does not mean "one byte" outside of plain English. The character 李 is a single glyph but 24 bits on disk. This is exactly why a five-character message can weigh more than five bytes, and why file sizes never quite match character counts for non-Latin text. If you also juggle other text-transport formats, the Base64 Encoder shows a related trick — repackaging those same bytes into a 64-character alphabet so they survive email and URLs intact.

Decoding: reading the bits back into text

Going the other way is just the same recipe in reverse. Given 01001000 01101001:

1. Chop the stream into 8-bit groups: 01001000, 01101001.
2. Read each group as a number: 01001000 = 64 + 8 = 72; 01101001 = 64 + 32 + 8 + 1 = 105.
3. Look the numbers up as code points: 72 → H, 105 → i.
4. Result: Hi.

Two things break decoding in practice. First, the bit count has to be a clean multiple of 8 (for ASCII and UTF-8 single bytes) — if you are missing a digit, the last group is incomplete and the conversion fails. A good decoder will tell you exactly how many bits you are short. Second, a stray character that isn't a 0 or a 1 (a typo'd lowercase l standing in for 1, say) will stop the parse; the decoder should name the position so you can fix it instead of staring at the whole string.

In the Text to Binary tool you don't paste back by hand — flip to "Binary → Text" mode, or hit Swap to send the current output straight into the input. It ignores spaces and 0b prefixes, so formatted output from anywhere round-trips cleanly. Run any UTF-8 string through forward and back, and if it comes out identical, you've confirmed the encoding is lossless.

Why this matters

Understanding text-to-binary is the foundation under every higher-level idea about how computers store and move data. File sizes, character corruption, "mojibake" garbled text, why an emoji takes four times the space of a letter — they all trace back to this one mapping from characters to code points to bytes to bits. Once you can convert A to 65 to 01000001 without thinking, the rest of the encoding world is just bigger tables and longer contracts.

---

Made by Toolora · Updated 2026-06-13