ASCII Table

ASCII (American Standard Code for Information Interchange) is the 7-bit character encoding standardized in 1963. It assigns a number 0–127 to each character: 32 control codes (0–31), 95 printable characters (32–126, starting with space), and DEL (127). The table above is a reference for those 128 mappings; nothing on this page leaves your browser.

The structure

The layout has consequences: digits are contiguous, so subtracting the ASCII code for 0 (48) from that for 5 (53) gives 5. Uppercase and lowercase letters are 32 apart, so tolower(c) = c | 0x20 for ASCII letters. The space character at 32 is the boundary between control-only and printable.

Control codes that still matter

Control codes came from terminal and communications conventions. Their interpretation depends on the protocol or application; common examples include:

The Unix vs Windows line-ending split is one of the longest-running compatibility headaches in computing. Unix uses LF (one byte). Windows uses CR LF (two bytes). Old Mac OS used CR alone. Tools that don’t normalize line endings produce silent diff noise across platforms.

ASCII vs Unicode vs UTF-8

ASCII is 7-bit (128 codes). Modern systems use Unicode, which assigns code points to characters across many writing systems. UTF-8 is the variable-length encoding that represents Unicode as bytes:

• ASCII characters (0–127) encode as themselves — one byte each. This is why a UTF-8 file containing only ASCII is byte-for-byte identical to a pure-ASCII file.
• Code points 128–2047 encode as two bytes.
• Unicode scalar values 2048–65535 encode as three bytes, excluding the surrogate range U+D800–U+DFFF.
• Unicode scalar values 65536–1114111 (U+10000–U+10FFFF) encode as four bytes.

ASCII is, in this sense, a strict subset of UTF-8. Anything that handles UTF-8 correctly handles ASCII correctly. The reverse isn’t true — code that assumes “one byte = one character” breaks immediately on non-ASCII text.

Where the ASCII table is the answer

• Reading raw bytes in a hex dump. 48 65 6c 6c 6f is Hello because 0x48 = 72 = H, etc. See hex to text.
• Designing a text-based protocol. ASCII printable characters are unambiguous; control codes have established meanings; non-ASCII bytes signal “this isn’t an ASCII protocol.”
• Checking an ASCII-only field. A protocol may require printable ASCII. Apply that constraint to the specific field; removing non-ASCII text from general logs would destroy valid names and messages.
• Implementing a parser. Most parser code paths only care about ASCII for syntax (keywords, punctuation) and only need Unicode-aware logic for string literals.
• Encoding choices. URL encoding, HTML entity encoding, and base64 all derive from “what subset of ASCII is safe in this context.”

The “extended ASCII” myth

There is no standard “extended ASCII.” Codes 128–255 are not part of ASCII; they’re part of whatever 8-bit encoding interprets the bytes — Latin-1, Windows-1252, MacRoman, KOI8-R, etc. Each assigns different characters to those 128 codes. A byte 0xE9 is é in both Latin-1 and Windows-1252, and И in KOI8-R. In UTF-8 it is a leading byte that needs two valid continuation bytes; it cannot stand alone.

When a website or file shows mojibake (garbled accented characters), it’s almost always a mismatch between the encoding the bytes were written in and the encoding the reader assumes.

Common pitfalls

• Assuming character ranges work for non-ASCII letters. [A-Za-z] matches ASCII letters only. é, ñ, 中 all fail. Use Unicode property classes (\p{L} in many regex flavors) when you mean “any letter.”
• Off-by-one with 0 vs 1 indexing. ASCII codes are unambiguously 0-indexed: NUL = 0, A = 65. Some legacy reference materials list them with column/row positions starting at 1, which can confuse readers used to 0-based arrays.
• Confusing decimal, octal, and hex. 65 decimal = 0o101 octal = 0x41 hex = A. Older Unix documentation uses octal heavily; modern tooling uses hex. The character is the same; the notation differs.
• Confusing a control character with its escape. JSON strings cannot contain a raw BEL byte or other unescaped U+0000–U+001F control character. The escape \u0007 is valid JSON and decodes to BEL; the receiving application decides what to do with it.

For text-to-byte conversion, see text to hex. For byte-to-character lookup at scale, see hex to text.

Sources and scope

Checked September 27, 2026: Unicode UTF encoding FAQ, UTF-8 specification, and JSON string grammar. Byte examples were also checked using Python codecs.