No. ASCII covers only 128 codes. Unicode covers nearly all modern writing systems. The first 128 Unicode code points preserve ASCII compatibility, which makes every ASCII text a valid UTF-8 text as well.
Carregando ferramenta… / Loading tool…
Look up ASCII, Latin-1 and Unicode blocks in decimal, hexadecimal, octal, binary and escapes
ASCII (American Standard Code for Information Interchange) is a set of 128 codes, from 0 to 127, that assigns a number to each character: controls (0 to 31 and 127), the space (32), punctuation, the digits 0 to 9 (48 to 57), the uppercase letters A to Z (65 to 90) and lowercase a to z (97 to 122). Because it uses only 7 bits, every character fits comfortably in a byte, and the same code can be read in decimal, hexadecimal, octal, binary or as a Unicode code point. One elegant design detail: uppercase and lowercase differ by exactly 32 (0x20), which turns case conversion into a simple bit operation. Even with Unicode powering the modern web, ASCII remains the compatible base for protocols, logs, escapes, shells, HTTP, JSON and many developer tools, since the first 128 Unicode code points are identical to ASCII. This tool goes beyond those 128: it browses Latin-1, Latin Extended-A, general punctuation, arrows, math symbols, box drawing and block elements, and shows, for every character, all the escape forms a programmer actually needs to copy.
Every character is just a number, and the various representations are different ways of writing that same number. Decimal is the human value; hexadecimal packs the byte into two digits (0x00 to 0x7F); octal, a legacy of minicomputers, still shows up in C string escapes and Unix file permissions; binary shows the bits; and the code point (U+0041) is the canonical Unicode form. Choosing one or another is convenience, not a change in value.
The table structure is deliberately ordered. Codes 0 to 31 and 127 are control characters and print no glyph: LF (10) breaks a line, CR (13) returns the carriage, TAB (9) tabulates, ESC (27) starts escape sequences. From 32 onward come the printables, with digits and letters in contiguous blocks, which is why sorting ASCII strings puts numbers before letters and uppercase before lowercase.
In practice, anyone opening a character table wants to paste that character into code. Each language has its own syntax: C and Java accept \x41 and the octal \101; JavaScript accepts \x41, \u0041 and, outside the BMP, \u{1F600}; Python accepts \x41, \u0041, \U0001F600 and also \N followed by the official character name in braces; HTML accepts the named entity when one exists, plus A and A; URLs use percent encoding over the UTF-8 bytes (%C3%A9); and CSS uses a backslash followed by hexadecimal digits.
Two traps show up every time. The first is the C hexadecimal escape, which consumes as many hex digits as it finds, so "\x41" followed by a letter from A to F changes value. The second is the difference between code point and byte: above 127, one character becomes several bytes in UTF-8, which is why the percent form of é has two groups (%C3%A9) while A has only one (%41).
Example 1, the letter A: 65 in decimal, 0x41 in hexadecimal, 101 in octal, 01000001 in binary and U+0041 as a code point. A single byte in UTF-8 (41), and identical escapes in almost every language. It is the simple case, and that is exactly why it is the reference everyone uses when reading a byte dump.
Example 2, uppercase to lowercase: A is 65 (0x41) and a is 97 (0x61); the difference is exactly 32. Since 32 is 0b100000, toggling a letter case means flipping a single bit. That is why old case conversion routines simply added or subtracted 32, or applied a mask with 0x20.
Example 3, the accent: é is U+00E9, still a single code point, but two bytes in UTF-8 (C3 A9). If a system counts bytes where it should count characters, a 20 character field holds less text in French or Portuguese than in English. Decomposing the text in the Text to codes tab shows exactly that gap between code points, UTF-16 units and bytes.
ASCII is daily bread for anyone debugging text: spotting a stray CR/LF that breaks a file, reading bytes in a line protocol (HTTP/1.x, SMTP), building escape sequences in regex and the terminal, or figuring out why an invisible character is tripping up a parser. The clear split between controls and printables is exactly what makes those diagnostics possible.
The limit is reach: ASCII covers only technical English, with no accents or other writing systems. Accents, arrows, math symbols and emoji live in Unicode, usually encoded as UTF-8, which keeps its first 128 code points identical to ASCII. That is why this tool goes past the ASCII block: Latin-1 covers Western European text, Latin Extended-A covers central Europe, and blocks such as arrows, math and box drawing cover terminal interfaces and technical documentation.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/ascii-table"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="ASCII Table"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
No. ASCII covers only 128 codes. Unicode covers nearly all modern writing systems. The first 128 Unicode code points preserve ASCII compatibility, which makes every ASCII text a valid UTF-8 text as well.
Everything runs in your browser: no search, text or code sequence leaves your device.