Interactive ASCII Table
Complete ASCII reference: decimal, hex, octal, binary, and character. Click any row to copy. Search or convert instantly.
Last reviewed: April 2026New to this tool? Click here for instructions
| Char | Dec | Hex | Oct | Bin | Name / Description |
|---|
How to use Interactive ASCII Table
To use the Interactive ASCII Table, simply visit the tool's page and explore the table. You can search for specific characters, convert characters to their ASCII values, and copy any character to your clipboard. This tool is a useful resource for developers, educators, and anyone interested in the ASCII character set.
When to use the tool in real workflows
The Interactive ASCII Table is ideal for developers working with text data, educators teaching ASCII and character encoding, and anyone needing to quickly look up ASCII values or convert characters. It's particularly useful when dealing with character encoding issues, debugging text-related problems, or simply needing a quick reference for ASCII characters.
How it works
The tool provides an interactive interface to view and interact with the ASCII character set. Users can search for specific characters, view ASCII values, and convert characters between different formats. The tool is built on a web-based platform, making it accessible from any device with an internet connection.
Tips, edge cases, or limitations
When using the tool, ensure you are looking up valid ASCII characters. The tool does not support extended ASCII characters beyond 127. Additionally, while the tool is free and accessible, it is not a substitute for the underlying principles of ASCII and character encoding. Always verify results with other sources when necessary.
Frequently Asked Questions
Look up any ASCII character by codepoint, glyph, or name and instantly see its decimal, hex, octal, binary, HTML entity, and escape sequence across multiple programming languages — entirely in your browser.
What This Tool Does
This is an interactive ASCII and extended-character reference that maps every codepoint from 0 to 255 to its glyph, its name, its numeric representations in four bases, its HTML entity, and its escape sequence in the major programming languages. Each row in the table is clickable: selecting a row reveals the full record (decimal, hexadecimal, octal, binary, HTML entity, JavaScript escape, C character literal, and Unicode codepoint notation) and copies the glyph to your clipboard.
The tool covers all three logical regions of the byte: control characters (0-31) that drive teletype-era signaling and modern terminal behavior, printable ASCII (32-126) that constitutes the universal lingua franca of text, and extended ASCII (128-255) that captures Latin-1 and Windows-1252 glyphs including accented letters, currency symbols, and typographic punctuation. Every lookup runs client-side — no codepoint you query is transmitted, logged, or stored outside your browser session. 🔒
How to Use It: Search by Codepoint, Name, Glyph, or Hex
The interface has three modes selectable via the chips at the top of the tool. Each mode targets a different lookup pattern; you'll typically switch between them as the question changes shape.
Table Mode: Browse the Complete Reference
Table mode renders all 128 standard ASCII rows by default, with checkboxes to toggle the control, printable, DEL, and extended-ASCII slices independently. Click any row to highlight it, copy its glyph to the clipboard, and open the detail card below the table — the card displays every encoded form of that codepoint side by side. The table header is sticky, so the column labels remain visible as you scroll through the 256-row extended view.
Search Mode: Find by Number, Glyph, or Name
Search mode accepts four input forms simultaneously: a decimal integer (65), a hexadecimal value with or without the 0x prefix (41 or 0x41), a literal single character (A), or a fragment of a character's name (backslash, tab, at, copyright). The search runs against all 256 rows and returns every match — so searching for "space" returns both SP (32) and the file/group/record/unit separators (28-31) and the non-breaking space (160).
Convert Mode: Three Linked Inputs
Convert mode displays three input fields (Character, Decimal, Hex) that update each other in real time. Type the letter A into the character field and the decimal field jumps to 65 and the hex field to 41; type 40 into the hex field and the character field shows @. The result panel below the inputs shows the full encoding set — HTML entity, hex entity, JavaScript escape, name, and description — and each result tile is itself click-to-copy.
Copy and Export Workflow
Every clickable surface in the tool calls DevToolbox.copyToClipboard() under the hood. Clicking a row in Table mode copies the glyph. Clicking any tile in Convert mode copies that specific representation. This means you can pivot quickly between, say, the HTML entity @ and the JavaScript escape \\u0040 without retyping anything — copy the form you need, paste into your code, then come back and copy a different form.
Worked Example: Looking Up the @ Symbol
The at-sign is a useful tutorial case because every common encoding shows it at a memorable, round value — decimal 64, hex 0x40, octal 0100, binary 0100 0000. Walking through it once cements the mental conversions between the four bases that the rest of the tool relies on.
- Character
@(commercial at, ASCII 64)- Goal
- Look up every encoded form for this single glyph and verify the conversions by hand
- Enter the lookup. Switch to Convert mode and type
@into the Character field. The Decimal field jumps to64and the Hex field to40. - Read the four base representations. Decimal 64, hexadecimal 0x40, octal 0100, binary 0100 0000. Each is a different way of writing the same byte value — only the radix differs.
- Verify the binary by hand. 64 = 26, so the binary representation has a single 1-bit in position 6 (counting from 0 on the right):
0100 0000. The leading zero bit confirms that this codepoint sits well within the 7-bit ASCII range (any value at or below 127 has bit 7 unset). - Verify the hex by hand. Each hex digit encodes four bits. Split the binary
0100 0000into nibbles:0100= 4,0000= 0. Concatenate to get 0x40. The hex value reads off the nibble pattern at a glance. - Verify the octal by hand. Octal digits encode three bits each. Group the 8-bit binary into three groups of three from the right (padding with a leading zero):
001 000 000. Read off: 1, 0, 0 — written as 0100 in octal (the leading zero is the conventional octal prefix in C-family languages). - Read the language-specific encodings. HTML entity:
@(decimal) or@(hex). JavaScript escape:"\\u0040". Python literal:chr(64)or"\\x40". C character literal:'\\x40'or simply'@'. Unicode notation:U+0040. - Copy the form you need. Click any tile in the result panel to copy that specific representation. The status bar confirms the copy with a green flash.
Expected output: seven encoding tiles for @: decimal 64, hex 0x40, octal 0100, binary 0100 0000, HTML entity @, JavaScript escape \\u0040, Unicode U+0040.
Common Use Cases
Debugging Character Encoding Issues
When text arrives looking like mojibake — strings of garbage characters where readable text was expected — the first diagnostic step is to dump the actual byte values and match them against the encoding table. A UTF-8 string interpreted as Windows-1252 produces a predictable pattern: an accented Latin letter encoded in UTF-8 as two bytes (for example, é = 0xC3 0xA9) shows up as the two glyphs é when displayed under Windows-1252. Looking up 0xC3 in this tool's extended table reveals it as Ã; looking up 0xA9 reveals it as ©. That immediate visual match confirms the encoding mismatch hypothesis and points to the correct fix — interpret the bytes as UTF-8 rather than Windows-1252.
Looking Up Control Characters During Protocol Work
HTTP, SMTP, FTP, and most line-oriented Internet protocols specify their delimiters in terms of ASCII control characters. Wireshark traces, raw socket dumps, and packet captures display these characters by their hex value or by their abbreviation (CR, LF, SP). When debugging a misbehaving protocol implementation, looking up the exact codepoint of each delimiter — 0x0D 0x0A for CRLF, 0x20 for SP, 0x09 for HT, 0x00 for NUL — confirms whether the wire format matches the specification. Off-by-one errors at the byte level are common; this tool gives a definitive reference for what each control byte represents.
Finding HTML Entities for Special Characters
Generating HTML programmatically requires escaping characters that have syntactic meaning in HTML: &, <, >, ", and '. Each maps to a numeric entity (&, <, >, ", ') or a named entity (&, <, >, ", '). The Convert mode of this tool returns both numeric and hex entity forms for any codepoint; clicking the entity tile copies it ready for use in templates or string-concatenation code.
Porting Code Between Languages
Each language has its own escape conventions for non-printing characters in string literals. C uses \\n, \\t, \\x41, and \\101; JavaScript uses the same plus \\u0041; Python adds \\N{LATIN CAPITAL LETTER A}; Java mirrors JavaScript; Rust uses \\x41 for byte escapes; Go uses \\u0041. When translating a string-processing function from Python to JavaScript or from C to Rust, looking up each non-trivial character in this tool produces the target language's escape form directly, eliminating the off-by-one errors that come from mental conversion between hex, octal, and decimal.
Designing Fixed-Width Terminal UIs
Box-drawing programs, retro terminal interfaces, and figlet-style banners rely on a constrained palette of printable ASCII glyphs plus a small set of Unicode box characters. Building a TUI layout in C or Rust requires looking up the exact codepoint of every drawing character — vertical bar (|, 0x7C), hyphen (-, 0x2D), plus sign (+, 0x2B), forward slash (/, 0x2F), backslash (\\, 0x5C). This tool's Convert mode gives the codepoint and the language-specific escape for each, which slot directly into format strings or render loops.
Edge Cases and Limitations
A few constraints and historical quirks are worth knowing before you trust an ASCII lookup blindly.
ASCII is fundamentally 7-bit. The original 1963 standard defines exactly 128 codepoints (0-127). The eighth bit in a byte was historically reserved for parity checking on noisy serial transmission. Everything above 127 belongs to one of the many incompatible extended-ASCII variants, not to ASCII itself. If a system says "ASCII" but uses values in the 128-255 range, it almost certainly means a specific extended variant — most likely Windows-1252 on Western systems.
Latin-1 (ISO-8859-1) and Windows-1252 differ in the 128-159 range. Latin-1 leaves codepoints 128-159 undefined (reserved for additional C1 control characters). Windows-1252 fills that range with printable typographic characters: curly quotes, the em dash, the en dash, the bullet, the trademark sign, and the euro. Microsoft's substitution is technically a violation of Latin-1 but became so widespread that browsers and most modern decoders silently treat declared Latin-1 documents as Windows-1252 when they encounter bytes in 128-159. This tool's extended table follows the Windows-1252 convention.
ASCII and UTF-8 are bit-for-bit compatible for the first 128 codepoints. Every valid ASCII file is also a valid UTF-8 file with no conversion. This is intentional design — UTF-8 was specifically engineered so that legacy ASCII data passes through UTF-8 systems unchanged. Bytes in 128-255 in a UTF-8 stream are not standalone characters but the leading or continuation bytes of multibyte sequences, which is why naive byte-by-byte parsing of UTF-8 as if it were single-byte ASCII produces mojibake on anything outside pure ASCII.
DEL is 127, not zero. DEL (delete) sits at the end of the ASCII range — codepoint 127 (0x7F). It dates to paper-tape punching: a fully punched byte (all seven bits set) was the universal "ignore this position" signal, because once a hole is punched it cannot be un-punched. NUL (codepoint 0) is the all-zero byte and serves a different role — string terminator in C, padding byte in many wire formats. Confusing the two is a classic bug source in low-level parsing code.
Backspace (BS, 0x08) versus the Backspace key. The ASCII BS control character (codepoint 8) instructs a teletype to move the printhead one position to the left. The physical Backspace key on a modern keyboard does not usually transmit BS; instead, terminals typically transmit DEL (0x7F) when Backspace is pressed and let the terminal emulator interpret it as "erase the previous character." This split is why stty erase on Unix is sometimes configured to ^H (BS) and sometimes to ^? (DEL), and why mis-configured terminals show ^? or ^H when the key is pressed instead of erasing.
Most control characters are dead in modern operating systems. Of the 33 ASCII control characters, only LF, CR, HT, NUL, ESC, and BEL see daily use. ETX (Ctrl+C interrupt), EOT (Ctrl+D end-of-input), and SUB (Ctrl+Z suspend or DOS end-of-file) appear in narrow contexts. The remainder — the device controls, the synchronization characters, the file/group/record/unit separators — survive only in legacy mainframe protocols and specialized binary formats. Their codepoints persist for backward compatibility, but encountering them in modern text data usually indicates a bug rather than intentional use.
Behind the Scenes: The History of ASCII
1963: The Original Standard
ASCII (American Standard Code for Information Interchange) was first published in 1963 by the American Standards Association, which later became ANSI. The standard grew out of teleprinter codes that themselves descended from Baudot code from the 1870s. The committee, chaired by Bob Bemer at IBM, aimed to replace a chaotic landscape of vendor-specific encodings — each computer manufacturer had its own incompatible character set — with a single industry-wide standard. Bemer also independently advocated for the ESC character (codepoint 27) as an extension mechanism for future encodings; his foresight on extensibility is why ANSI escape sequences for terminal colors and cursor control still work today.
The Decision to Use 7 Bits
The choice of 7 bits was not arbitrary. Six bits would have provided only 64 codepoints, insufficient for upper-case letters, lower-case letters, digits, punctuation, and control characters simultaneously. Eight bits would have used the entire byte width but required all systems to commit to a specific glyph in the high range, foreclosing future regional encodings. Seven bits split the difference: enough room for the full English alphabet in both cases, plus digits, punctuation, and control codes, while leaving the eighth bit free for the parity scheme that early serial communications relied on to detect transmission errors over noisy modem and teletype lines.
ANSI X3.4-1986: The Final Form
The standard was revised several times between 1963 and 1986, with the final canonical version published as ANSI X3.4-1986 (later republished as ISO 646 internationally). The 1986 edition consolidated minor variations from earlier revisions and locked in the 128-codepoint table that every subsequent standard — including Unicode — preserves intact. Unicode's first 128 codepoints are by definition identical to ASCII, which is why ASCII files remain valid Unicode and UTF-8 files four decades after the standard was finalized.
Why @ Lives at 0x40
The commercial at sign sits at codepoint 64 (0x40) for a reason rooted in the structure of the table. Hex 0x40 is one position before A at 0x41 — the start of the uppercase Latin alphabet block. The character immediately before each alphabetic block in ASCII is a special punctuation glyph (@ before A-Z; backtick ` at 0x60 before a-z). This was the committee's choice for symbol placement in the otherwise-tight slots between the digits-and-punctuation block (0x20-0x3F) and the letter blocks (0x40-0x7E). On some non-US national variants of ISO 646 (the international 7-bit standard derived from ASCII), the @ slot was reassigned to language-specific characters — Danish replaced it with Æ, French with à — which is why pre-Unicode keyboards in some countries lacked an @ key and email addresses were difficult to type.
Why We Have a Backslash
The backslash at codepoint 92 (0x5C) was added late in ASCII's development specifically to support the ALGOL programming language, which used the symbol pair /\ (forward slash then backslash) and \/ (backslash then forward slash) for the logical AND and OR operations. Backslash has no historical typewriter or mathematical antecedent — it was effectively invented for ASCII. The choice turned out to be enormously consequential: backslash became the universal escape character in C, the path separator on Windows, the delimiter in regular expressions, and the marker for special sequences in nearly every modern programming language. None of that was anticipated by the ASCII committee; backslash exists because of ALGOL.
Comparison: ASCII vs Unicode vs UTF-8/16/32 vs EBCDIC
ASCII is one point in a larger landscape of character encodings, each with different trade-offs between coverage, byte cost, and compatibility. The table below summarizes the major encodings you are likely to encounter in modern systems.
| Encoding | Code Units | Bytes per Character | Coverage | ASCII-Compatible | Typical Use |
|---|---|---|---|---|---|
| ASCII | 7-bit | 1 (with parity bit unused) | 128 codepoints, English only | Yes (by definition) | Legacy files, source code, configuration |
| Latin-1 (ISO-8859-1) | 8-bit | 1 | 256 codepoints, Western European | Yes for 0-127 | Old web pages, HTTP headers |
| Windows-1252 | 8-bit | 1 | 256 codepoints, Western European + typographic | Yes for 0-127 | Default on Windows pre-Unicode era |
| UTF-8 | 8-bit | 1 to 4 (variable) | All 1,114,112 Unicode codepoints | Yes (1 byte for 0-127) | Web standard, modern files, JSON, XML |
| UTF-16 | 16-bit | 2 or 4 (surrogate pairs above U+FFFF) | All Unicode codepoints | No (every byte is half of a code unit) | Windows native APIs, Java/JavaScript strings in memory |
| UTF-32 | 32-bit | 4 (fixed) | All Unicode codepoints | No | Internal codepoint storage; rare in files |
| EBCDIC | 8-bit | 1 | 256 codepoints, IBM mainframe variants | No (entirely different ordering) | IBM z/OS mainframes, AS/400 (IBM i) systems |
Two implications follow from this comparison. First, UTF-8 is the correct default choice for any new file format, network protocol, or storage system: it handles every character in every writing system while preserving bit-for-bit compatibility with legacy ASCII tools. Second, EBCDIC remains a real concern for any system that exchanges data with IBM mainframes — a CSV file written in EBCDIC and read as ASCII produces garbage at every character position, not just at accented letters, because the codepoint ordering itself differs.