Understanding binary text
Eight bits, one letter, no magic.
What converting text to binary actually means, and why "the same letter" can have two different bit patterns depending on the encoding.
What "binary" really means here.
Every byte is eight bits. Every byte is a number from 0 to 255. Every character in a plain ASCII string is one byte. Convert each character to its eight-bit binary and you have the "binary representation" of the text. Nothing transformative happens — the same byte stream that's in memory, written in a different alphabet. The string "A" lives in your computer as the byte 65, which in binary is 01000001. That's it.
1 byte ≡ 8 bits ≡ 1 ASCII character
ASCII — the 128-character world.
ASCII assigns the first 128 codes (0–127) to specific characters: control codes in 0–31 and 127, printable characters in 32–126. The capital letters A–Z occupy 65–90; the lowercase a–z occupy 97–122; the digits 0–9 occupy 48–57. Notice that the gap between capital and lowercase is exactly 32 — flipping one bit changes case. That's not an accident; ASCII was designed so common transformations were single bit operations on 1960s hardware. As long as your text is plain English without accents, "convert to binary" maps neatly: one character, eight bits, no surprises.
Once you leave ASCII, things change.
The character "é" is not one byte in modern UTF-8 — it's two bytes, 11000011 10101001. The character "🦊" is four bytes. Emoji, accented letters, non-Latin scripts, mathematical symbols — they all live above byte value 127 and are encoded as multi-byte sequences. The bit count of a binary representation depends on the encoding the converter uses; "the binary of this string" is only unambiguous once you've fixed UTF-8 (or any other encoding) as the rule.
A worked round trip.
The word "Hi" — two ASCII characters. H is 72; i is 105. In binary: 01001000 01101001. Read those bits in groups of eight, look up each byte in the ASCII table, and you're back to "Hi". The conversion is lossless and the maths is the same in every direction.
"Hi" → binary
ASCII: H=72, i=105
Each byte becomes an 8-bit group.
72 = 01001000 ; 105 = 01101001
= 01001000 01101001
"Café" in UTF-8
C=67, a=97, f=102, é=2 bytes 195/169
é needs two bytes in UTF-8 because its code point is 233.
C → 01000011 ; a → 01100001 ; f → 01100110 ; é → 11000011 10101001
= 5 bytes for 4 visible characters
Endianness and bit ordering.
Within a single byte the convention is "most-significant bit first" — leftmost bit is worth 128, rightmost is worth 1. That ordering is universal. Across multiple bytes, things vary: a 4-byte integer can be stored most-significant-byte-first (big-endian, network byte order) or least-significant-byte-first (little-endian, x86 native). For plain text, this only matters with UTF-16 and UTF-32 — the original UTF-8 was deliberately designed to avoid byte-order ambiguity, which is one of the reasons it won.
Why this is useful, beyond curiosity.
The practical value of being able to see binary is debugging at the byte level — when a file has an unexpected BOM, when a "blank" string is full of zero-width characters, when an API silently double-encodes UTF-8, when a hash mismatch comes from a stray trailing newline. Looking at the bits tells you exactly what's there, in a way the rendered string can't. The tool here is also a teaching aid: a kid who's just learned about powers of two can paste their name and see the math work.
What this isn't.
Converting to binary isn't encryption, isn't compression, and isn't a code. The output is a one-to-one map of the input — anyone who knows the encoding (and that's everyone) can read it back. If your goal is to hide a message from a casual reader, you want a cipher; the binary view is closer to looking at the same letter through a magnifying glass than it is to translating it.