What the ASCII Table Contains and How the Codes Are Organised
ASCII assigns a number to each of 128 characters, and that mapping underpins every text file, HTTP header, and source file you have ever opened. This table lists all of them, from 0 to 127, with the decimal value, the hexadecimal, the octal, the eight-bit binary, the character itself, and a plain description of what it does. Developers debugging a stubborn string comparison, students learning how text becomes bits, and anyone staring at a hex dump wanting to know what 0x0A means all need this open in a tab. The search box filters as you type, which beats squinting at a static chart image.
The layout of the codes is deliberate rather than arbitrary, and knowing the structure means you can often work out a value without looking. Codes 0 to 31 plus 127 are control characters: they instruct rather than print, covering null at 0, tab at 9, line feed at 10, carriage return at 13, escape at 27, and delete at 127. Code 32 is the space, the first printable character. Digits 0 through 9 occupy 48 to 57, so the numeric value of a digit character is simply its code minus 48. Uppercase A through Z sit at 65 to 90, lowercase a through z at 97 to 122, and the gap of exactly 32 between the two cases is why bit five alone distinguishes them — flipping that single bit toggles the case, which is how early case-conversion routines worked. Punctuation fills the remaining blocks around them. Every code fits in seven bits, so the eighth bit of a byte was historically free, which is exactly what UTF-8 later exploited.
A lookup in practice. You are reading a hex dump and see the bytes 48 65 6C 6C 6F 0D 0A. Search 48 in hex and the table gives decimal 72, character H. Then 65 hex is decimal 101, e. 6C is 108, l, appearing twice. 6F is 111, o. So far the word Hello. Then 0D is decimal 13, carriage return, and 0A is decimal 10, line feed — together the Windows line ending CRLF. That pair is the answer to a large share of confusing bugs: a file written on Windows carries both bytes, a file written on Linux carries only 0A, and a naive string comparison between them fails on an invisible difference. Search for the word carriage in the box and you land on code 13 directly.
Specific moments this gets used. A developer whose form validation rejects a valid email discovers the pasted value ends in code 13 that came from a spreadsheet cell. Someone writing a CSV parser needs to strip codes 9, 10, and 13 and wants their exact values rather than guessing. A student implementing a Caesar cipher needs 65 and 97 as the offsets for the two letter ranges. An engineer working with a serial device sends escape at 27 to start a control sequence and needs the byte value for the driver. A tester building an input fuzzer picks the null character at 0 to check whether a field truncates.
A few clarifications worth having. ASCII stops at 127, so accented letters, currency symbols beyond the dollar, and every emoji live outside it — those belong to UTF-8, which keeps the first 128 code points identical to ASCII and uses multi-byte sequences beyond. That compatibility is why a plain English text file is valid UTF-8 without conversion. The pitfall to watch is anything described as extended ASCII: codes 128 to 255 were never standardised, and different code pages assign them differently, so a file interpreted with the wrong one produces the mangled characters you see in badly imported data. If your text has any character outside this table, treat the encoding as UTF-8 and be explicit about it. The whole reference is built into the page and runs in your browser, so nothing you search is uploaded and it keeps working offline.
