é turns into é somewhere between being saved and being displayed. No bytes were corrupted, nothing was lost — the exact same two bytes just got read twice, under two different assumptions about what number-to-character table applies above 127. That gap is the entire bug, and it exists because ASCII itself never defined anything above 127 in the first place.
The same two bytes, two different readings
é is U+00E9, which UTF-8 encodes as two bytes: 0xC3 0xA9. A correct UTF-8 decoder sees 0xC3 and knows, from the bit pattern alone, that it's the first byte of a two-byte sequence — so it consumes 0xA9 right along with it and produces one character. A decoder that instead treats every byte as a standalone character — the Latin-1 / Windows-1252 assumption — reads 0xC3 as à and 0xA9 as © on their own, independently, and prints both:
input: "é" → UTF-8 bytes 0xC3 0xA9
read one byte at a time as Latin-1 / Windows-1252
é
0xC3 is read as its own character (Ã), then 0xA9 as its own character (©) — two wrong characters from one right one
read as the UTF-8 sequence it actually is
é
the decoder recognizes 0xC3 as the start of a 2-byte sequence and consumes 0xA9 as its continuation
This is mojibake, and "é" specifically is its most common signature — it's what you get, every time, from exactly this one mistake applied to exactly this one letter.
ASCII only ever defined 0 through 127
The confusion is baked into the name people give byte 233: "extended ASCII." There's no such standard. ASCII is specifically the 7-bit set, codes 0 through 127; everything from 128 to 255 was left undefined, and a dozen incompatible vendors filled it in independently — Windows-1252, ISO-8859-1, Mac OS Roman, and others each assign that range differently. A single byte value above 127 doesn't have one correct character; it has as many as there are code pages willing to claim it. ASCII Converter reflects this directly: é (233) still renders as two hex digits and eight bits, the same shape as a true ASCII byte, but its isAscii flag reads false — flagged rather than silently treated as one. Guessing a code page would just be choosing which mojibake to produce.
127 looks printable. It isn't.
The common shortcut for "printable ASCII" is codes 32 through 127. It's off by one: 32 through 126 is printable, and 127 — sitting immediately after printable ~ at 126 — is DEL, a control character with no glyph of its own. It's the only control code at the top of the table instead of the bottom, which is exactly why the shortcut keeps being slightly wrong.
The other 32 control characters still do real work
Codes 0 through 31 aren't padding — they're a quarter of the entire ASCII table, and several are still load-bearing today: NUL (0) terminates every C string, LF (10) and CR (13) are the two halves of a line ending that Windows uses together and Unix uses one of, HT (9) is a tab, and ESC (27) is what every terminal escape sequence — including the ones that color your terminal output — begins with. None of them have a printable glyph, which is why a tool that inspects them has to look their meaning up by table rather than display them directly.
Try it yourself
ASCII Converter breaks text down in decimal and binary for the true 7-bit range, names all 33 control characters, and flags anything above 127 instead of guessing a code page for it. For the UTF-8/UTF-16 byte-level view behind the mojibake example above, see Hex Encode; for the full Unicode picture beyond single bytes, see Unicode Converter. Runs entirely in your browser.