Seven bits, four bases
ASCII defines 128 codes, 0 through 127, which fits in seven bits. The eighth bit of a byte was originally a parity bit for error checking on serial lines, and that is the historical reason the standard stops where it does rather than running to 255.
The four numeric columns above are the same value written differently. Hex is what you see in a hex editor and in escape sequences like \x41. Octal survives in C escapes ('\101') and in Unix file permissions, both of which predate hex being convenient. Binary makes the bit tricks visible: uppercase A is 01000001 and lowercase a is 01100001, differing in exactly one bit. That is not a coincidence — the layout was designed so that case conversion is c ^ 0x20, and so that a digit's numeric value is c - 48. A surprising amount of old parsing code is built on those two facts.
The control characters are not decoration
Codes 0 to 31 and 127 do not print. They were instructions to a teleprinter, and several are still load-bearing. 10 (LF) and 13 (CR) are the line-ending problem in its entirety: Unix, macOS and every network protocol on the web end lines with LF alone, while Windows text files use CR followed by LF. A file moved between the two shows either stray ^M characters at the ends of lines or no line breaks at all, depending on which direction it went.
27 (ESC) starts every ANSI terminal sequence, so the red text your program prints is really ESC [ 3 1 m. 0 (NUL) ends strings in C. 9 (HT) is tab. 7 (BEL) still makes terminals beep. 3 and 4 are what Ctrl+C and Ctrl+D send, and the general rule holds: a Ctrl combination sends the letter's code minus 64, which is why Ctrl+A is 1 and Ctrl+Z is 26.
The one that catches people out is 19 (XOFF, Ctrl+S). Press it in a terminal by muscle memory reaching for save, and the terminal stops updating and looks frozen. Ctrl+Q (17, XON) resumes it.
Why there is no extended ASCII table here
A byte holds 256 values and ASCII only claims 128 of them, so through the 1980s every vendor and country filled the upper half with something different. Latin-1 (ISO-8859-1) put Western European accented letters there. Windows-1252 is nearly Latin-1 but replaces a block of unused control positions with curly quotes and the em dash, which is why text pasted from Word sometimes arrives as question marks. CP437 on the original IBM PC put box-drawing characters there. KOI8-R held Cyrillic; Shift-JIS and EUC-KR used the upper half as lead bytes for multi-byte sequences entirely.
So the byte 0xE9 is é in Latin-1, Ð in CP437, and the first half of a Japanese character in Shift-JIS. Asking "what character is 233 in extended ASCII" has no answer without naming the encoding, and any table that gives you one has quietly picked Latin-1 for you. Above 127 this tool reports the Unicode code point and says explicitly that it is not ASCII.
How UTF-8 keeps the old table intact
UTF-8 was designed so that the 128 ASCII codes encode as themselves, one byte each, with the high bit clear. Everything else uses two to four bytes, all of which have the high bit set. That single property is why UTF-8 won: a pure-ASCII file is already valid UTF-8 with no conversion, and old code that scans for ASCII delimiters like / or \n cannot accidentally match the middle of a multi-byte character.
The practical consequence is that byte counts and character counts diverge the moment non-ASCII text appears. A Latin letter is one byte, most accented and Greek letters are two, Chinese, Japanese, Korean and most other scripts are three, and emoji are four. A database column declared VARCHAR(255) in bytes holds 255 English characters or 85 Korean ones — the same mismatch that shows up as truncated text after a migration.
Questions people ask
I typed 7 and got the bell character rather than the digit 7. Why?
A bare number is read as a code, so 7 resolves to BEL. The digit character 7 has code 55. To look up the digit, type it as part of a longer string, or read it off the full table where the printable digits occupy 48 through 57.
Are 65, 0x41 and 0o101 all the same thing?
Yes — decimal, hexadecimal and octal spellings of one value, the letter A. The prefixes are what disambiguate them, which is why this tool requires 0x and 0o rather than trying to infer the base. In C and in most shells the same character is written \x41 or \101.
Why does my string length not match the number of characters I typed?
Two separate reasons. If you are counting bytes, non-ASCII characters take two to four of them in UTF-8. If you are counting JavaScript string length, that counts UTF-16 code units, so anything above U+FFFF — emoji, rare Han characters — counts as two. The Unicode inspector on this site breaks a string down along all of those axes at once.
Is ASCII still worth knowing, or is it a museum piece?
It is still the substrate. HTTP headers, most protocol keywords, JSON syntax characters, filenames on almost every system and the first 128 code points of Unicode are all ASCII, unchanged since 1967. What is obsolete is treating a byte as a character, which stopped being safe the moment anything outside this table appeared in the data.