How Text Becomes Bytes: Binary, Hex, and UTF-8 Explained

You type the letter A into a text editor and save the file. The file is 1 byte. You type A again and add C — two bytes. You type café and save. The file is 5 bytes, not 4. You open the same file in a different program and see café. Somewhere between writing and reading, the encoding was misinterpreted.

Understanding why this happens — and how to see it — is the difference between debugging encoding problems and guessing at them.

The Binary Text Translator encodes and decodes text in real time so you can see exactly what bytes each character produces.

Text is not stored as characters

Computers store numbers. Every character in a text file is stored as one or more numbers. The mapping from character to number is called an encoding. The most common is UTF-8, which is the default for virtually all modern systems.

In ASCII (the predecessor to UTF-8), each character is exactly 7 bits — 128 characters, covering uppercase and lowercase Latin letters, digits, punctuation, and control codes:

A = 65  = 01000001
B = 66  = 01000010
a = 97  = 01100001
1 = 49  = 00110001

The same bytes, regardless of platform, font, or program.

UTF-8: one to four bytes per character

UTF-8 solves the limitation of ASCII by using variable-length encoding. Characters in the ASCII range use 1 byte (the same bytes as ASCII). Non-ASCII characters use 2, 3, or 4 bytes.

The encoding scheme:

Code point range	Bytes	Example
U+0000–U+007F	1	A = 41
U+0080–U+07FF	2	é = C3 A9
U+0800–U+FFFF	3	é = E9 80 80 (varies)
U+10000–U+10FFFF	4	emojis

The key property: UTF-8 is backward-compatible with ASCII. Any valid ASCII file is a valid UTF-8 file.

The é in café has a code point of U+00E9. In UTF-8 it is encoded as the two-byte sequence C3 A9. That is why café is 5 bytes: c a f (1 byte each) + é (2 bytes) + the ASCII e.

Binary and hexadecimal representation

Bytes are sequences of 8 bits. Binary notation shows each bit: 01000001. Hexadecimal groups those 8 bits into two 4-bit nybbles, each representing 0–15:

Binary:   0100 0001
Hex:      4    1
Decimal:  65
Character: A

Hex is preferred for inspecting bytes because it is compact and unambiguous — each byte is exactly two hex characters.

The same string in different representations:

Input:  Hello
ASCII:  48 65 6c 6c 6f
Binary: 01001000 01100101 01101100 01101100 01101111
Hex:    48 65 6c 6c 6f

Input:  café
UTF-8:  63 61 66 C3 A9
Binary: 01100011 01100001 01100110 11000011 10101001
Hex:    63 61 66 C3 A9

The decoding pitfall

When a UTF-8 file is read as Latin-1 (ISO-8859-1), each byte is interpreted as a single character. C3 A9 becomes two characters: Ã (code point 195) and © (code point 169) — the garbled é you see when a UTF-8 file is opened as Latin-1.

Conversely, when a Latin-1 file is read as UTF-8, code points above 127 trigger a "valid UTF-8 continuation byte expected" error, or they are replaced with the replacement character U+FFFD.

The fix is always to know the encoding before interpreting bytes. HTTP responses include a Content-Type: text/html; charset=UTF-8 header. Files can declare an encoding in a BOM (byte order mark — EF BB BF at the start of a UTF-8 file) or in a meta tag (<meta charset="UTF-8">). The Binary Text Translator lets you switch encodings and see the decoded result immediately.

Multi-byte characters in code

If you are counting characters in a JavaScript string, café.length gives 5 — because JavaScript counts UTF-16 code units, and é requires two. If you are writing a database column that must fit 10 characters and your data is in Japanese, you need to know whether the database counts characters or bytes. MySQL's VARCHAR(10) counts characters; VARBINARY(10) counts bytes. A 10-character Japanese string can be 30+ bytes.

// JavaScript: length is code units, not visual characters
"café".length         // 5
"日本語".length        // 3 (each is one UTF-16 code unit, but…)
"🎉".length            // 2 (emoji is a surrogate pair in UTF-16)

For accurate character counts across all Unicode, use Array.from(str).length or the Intl.Segmenter API.

Why hex is used in security and debugging

Hex appears everywhere in security contexts because it makes byte sequences human-readable. A TLS certificate fingerprint is shown in hex. A hash output is shown in hex. A memory dump is hex. When debugging a protocol, looking at the raw hex tells you exactly what bytes crossed the wire, regardless of what encoding the receiving application assumed.

The Number Base Converter handles conversions between binary, decimal, octal, and hex for any integer — useful when you need to translate a byte value from one representation to another.

Encoding and encryption are different

Text encoding (UTF-8, Latin-1) is not encryption. café encoded in Base64 is Y2Fmw6k= — trivially reversible. Encryption with a key produces output that cannot be decoded without the key. The Text Encryptor uses AES encryption for that — Base64 is merely a way to represent binary data as ASCII text.

The Binary Text Translator shows you exactly what is in your text — paste any string and see its binary, hex, and decimal representations side by side.