ASCII table

All 128 codes, with the control characters explained rather than left as blank cells.

To see a whole string in binary, hex and UTF-8 bytes at once, use the text to binary converter.

Control characters (0–31)

Printable characters (32–126)

Delete (127)

Why the table is laid out this way

ASCII is seven bits, giving 128 codes, and almost none of the arrangement is arbitrary. Three decisions are worth knowing because they are still exploited in code today.

Digits start at 48. The low four bits of each digit code are the digit's own value, so c - '0' converts a character to a number, and c & 0x0F does the same with a mask. Every parser ever written relies on this.

Capitals and lowercase are 32 apart. A is 65 and a is 97; Z is 90 and z is 122. Thirty-two is a single bit, so c ^ 32 flips case and c | 32 forces lowercase. This is why case-insensitive comparison used to be free.

Control characters map to Ctrl plus a letter. The Ctrl key originally cleared the top two bits of the keyboard code. C is 67, so Ctrl+C sends 3, which is ETX, end-of-text. That is the entire reason Ctrl+C interrupts a program, Ctrl+D signals end-of-file, and Ctrl+G makes the terminal beep.

The control characters that still matter

ASCII, Latin-1 and UTF-8

ASCII defines only 0–127. Everything above that — accented letters, currency symbols, anything non-English — belongs to some other encoding, and the confusion between them is where mojibake comes from.

UTF-8 was designed so that its first 128 code points are byte-for-byte identical to ASCII. Any ASCII file is already valid UTF-8, which is the single reason UTF-8 won: existing files and existing C code kept working unchanged. Characters above 127 become two to four bytes, each with its high bit set, so they can never be mistaken for an ASCII character.

That is why a UTF-8 file read as Latin-1 shows é where é should be: the two bytes of the UTF-8 encoding are being displayed as two separate Latin-1 characters. The bytes are correct; the interpretation is not.