ASCII Table Reference shows all 128 standard ASCII characters with their decimal, hexadecimal, octal, and binary representations, plus HTML entities and keyboard shortcuts. Search by character, code, or description to quickly find the encoding you need. Useful for understanding escape sequences, building text processors, debugging encoding issues, and working with low-level protocols that use ASCII control codes.
ASCII (American Standard Code for Information Interchange) was defined in 1963 and assigns 128 characters to values 0-127. Characters 0-31 are control characters (non-printable): NUL (0), SOH (1), STX (2), ETX (3), EOT (4), ENQ (5), ACK (6), BEL (7, bell/beep), BS (8, backspace), HT (9, horizontal tab), LF (10, line feed/newline), VT (11, vertical tab), FF (12, form feed), CR (13, carriage return), SUB (26, Ctrl+Z), ESC (27, escape), DEL (127). Characters 32-126 are printable: space (32), digits 48-57, uppercase A-Z (65-90), lowercase a-z (97-122).
Extended ASCII (characters 128-255) is NOT standard ASCII -- different encodings (Latin-1/ISO-8859-1, Windows-1252, OEM 437) assign different characters to these values. Unicode UTF-8 is the modern standard (covers 1.1 million+ code points). ASCII characters 0-127 are identical in UTF-8 (single byte). For modern systems, prefer Unicode; ASCII knowledge remains essential for protocol design, network programming, and legacy system interaction.
LF (Line Feed) character
Result: Decimal: 10, Hex: 0x0A, Binary: 00001010, Escape: \n, Ctrl: Ctrl+J
ESC (Escape) character
Result: Decimal: 27, Hex: 0x1B, Binary: 00011011, Escape: \x1b, Use: ANSI escape sequences
@ symbol
Result: Decimal: 64, Hex: 0x40, Binary: 01000000, HTML: @, Keyboard: Shift+2
What are ASCII control characters and what do they do?
Control characters (ASCII 0-31 and 127) are non-printable characters originally designed to control teletype machines and serial communication. Important ones: NUL (0): null terminator for C strings -- marks end of string. BEL (7): bell/beep -- some terminals still produce a sound. BS (8): backspace -- moves cursor one position left. HT (9): horizontal tab -- \t in strings. LF (10): line feed / newline -- \n -- the standard line separator on Unix/Linux. CR (13): carriage return -- \r -- moves to start of line. Windows uses CR+LF (\r\n) for line endings. ESC (27): escape -- starts ANSI terminal escape sequences for colors/cursor movement. DEL (127): delete -- was the backspace on some systems.
What is the difference between ASCII, Latin-1, and Unicode?
ASCII: 128 characters (0-127). English alphabet, digits, common symbols, control codes. Designed for English-only communication in the 1960s. Latin-1 (ISO 8859-1): 256 characters (0-255). ASCII for 0-127, then adds accented characters (a-umlaut, e-acute, n-tilde, etc.) for Western European languages. Windows-1252 is similar but slightly different at positions 128-159. Unicode: 1.1 million+ code points. Covers all human writing systems plus emoji, mathematical symbols, etc. UTF-8 is the dominant encoding: ASCII characters use 1 byte (bytes identical to ASCII). Non-ASCII characters use 2-4 bytes. Today, 98%+ of web pages use UTF-8.
How do ANSI escape sequences use ASCII?
ANSI escape sequences start with ESC (ASCII 27, hex 0x1B) followed by [ and then a series of parameters. In terminal output: \x1b[31m = red text. \x1b[32m = green text. \x1b[0m = reset colors. \x1b[1m = bold. \x1b[2J = clear screen. \x1b[A = move cursor up. These are widely used in terminal output from tools like git, npm, compilers, test runners. In Python: print('\x1b[31mError\x1b[0m'). In Go: fmt.Println('\x1b[32mOK\x1b[0m'). Libraries like chalk (Node.js), colorama (Python), or termcolor handle this for you. Some Windows terminals require enabling ANSI support.
Why does Windows use CRLF line endings instead of just LF?
Historical reason: the CR (carriage return, \r) and LF (line feed, \n) characters come from typewriter/teletype operation. CR moves the print head back to the start of the line. LF advances the paper one line. On Unix (1970s), just LF became the newline character. On Windows (inheriting from MS-DOS which inherited from CP/M), CR+LF (\r\n) was used to match the original two-character sequence. Practical impact today: Git converts line endings on checkout (core.autocrlf). Text editors on Windows handle both. cross-platform tools use \n. In Python, open() in text mode normalizes to \n on all platforms. Use \r\n explicitly only when writing protocols (HTTP, SMTP) that require it.
How do I detect and handle non-ASCII characters in code?
Python 3: strings are Unicode by default. To detect non-ASCII: any(ord(c) > 127 for c in s). To encode to ASCII with error handling: s.encode('ascii', errors='replace') or 'ignore' or 'xmlcharrefreplace'. To check encoding: chardet.detect(bytes_data) for unknown encodings. JavaScript: /[^\x00-\x7F]/.test(str) for non-ASCII regex test. Go: for i, r := range str { if r > 127 { ... } } since range iterates Unicode code points. Java: str.chars().anyMatch(c -> c > 127). For file reading, always specify encoding: Python open('file', encoding='utf-8'). For web forms, always use accept-charset='UTF-8' and set Content-Type to UTF-8.