The first time ASCII genuinely mattered to me, I was debugging a CSV import for a WordPress plugin that kept splitting one customer's address into two rows. The file looked fine in every editor I opened it in. It turned out one export had used a bare carriage return (code 13) as a line ending while my parser expected a line feed (code 10), and a stray record separator (code 30) had crept in from a mainframe export upstream. None of those characters print anything. You cannot see them. You can only see them if you have a table that turns the invisible byte into a number and a name - which is exactly why I built the ASCII Table on toolz.dev and why I keep it pinned in a browser tab.
TL;DR: ASCII maps every basic English character and a set of control signals to the numbers 0–127; extended sets like ISO 8859-1 (Latin-1) fill in 128–255. Capital
Ais 65, lowercaseais 97, space is 32, and the "invisible" codes 0–31 are control characters like tab (9), line feed (10), and carriage return (13). If you can read the table, you can decode almost any text-encoding bug, escape any character safely in HTML, and understand why UTF-8, JSON, and every programming language behave the way they do with strings.
I've spent years building things that live and die on text handling - a WordPress admin plugin, Laravel APIs, React front ends - and I can tell you that a working mental model of ASCII saves more debugging hours than almost any other piece of low-level knowledge. This guide is the version I wish someone had handed me early.
What is ASCII and why does it still matter?
ASCII stands for the American Standard Code for Information Interchange. It was first standardised in 1963 and settled into the form we still use as ANSI X3.4-1986 (also published internationally as ISO/IEC 646), and the network definition still cited today is RFC 20 (1969). At its heart it is a lookup table: a mapping from the numbers 0 through 127 to a specific set of characters and control signals. Seven bits, 128 slots, one agreement that the whole computing world could share.
That agreement is the reason a text file written on a Linux server in 1990 still opens correctly on a Mac laptop today. Before standard character codes, every manufacturer had its own scheme, and moving text between machines was a translation problem. ASCII fixed the lower 128 codes in place, and it has never moved since.
What surprises people is how much of modern computing still rests directly on it. Unicode - the giant standard that covers emoji, Chinese, Arabic, and every other script - deliberately makes its first 128 code points identical to ASCII. UTF-8, the encoding that powers the web, encodes those first 128 code points as single bytes with the exact ASCII values. So a plain ASCII text file is also a valid UTF-8 file, byte for byte. When you understand ASCII, you have understood the foundation the rest of text encoding is built on.
How is the ASCII table organised?
The 128 standard codes fall into a few natural groups, and knowing the group is often more useful than memorising any single value.
Control characters (0–31 and 127). These are the non-printing codes. They carry instructions rather than glyphs: null (0), bell (7), backspace (8), horizontal tab (9), line feed (10), carriage return (13), escape (27), and delete (127) are the ones you'll actually meet. They were designed to drive teletype machines, and their ghosts still run everything from line endings in your source files to the escape sequences that colour your terminal output.
Printable punctuation and symbols (32–47, 58–64, 91–96, 123–126). Space is 32 - the lowest printable code, and technically a printing character even though it shows nothing. The rest are the symbols scattered around your keyboard: ! is 33, @ is 64, ~ is 126.
Digits (48–57). The characters 0 through 9 sit in a neat run from 48 to 57. That ordering is deliberate: subtract 48 from a digit's code and you get its numeric value, which is how nearly every "parse a number from a string" routine begins.
Uppercase letters (65–90) and lowercase letters (97–122). A is 65, Z is 90; a is 97, z is 122. The gap between a letter's uppercase and lowercase form is always exactly 32.
The extended range (128–255) is a different animal, and it's where most confusion lives - so it gets its own section below.
What is the difference between ASCII and extended ASCII?
Standard ASCII only defines 128 codes because it only uses seven bits. But computers store text in eight-bit bytes, which leaves a whole extra 128 slots (128–255) unused by the standard. "Extended ASCII" is the umbrella term for the various schemes that fill those slots.
The catch - and it's a big one - is that there is no single extended ASCII. Different code pages assign the upper 128 codes completely differently. IBM's code page 437 put box-drawing characters there. Windows-1252 put curly quotes and the euro sign there. ISO/IEC 8859-1, known as Latin-1, put accented Western European letters there. A byte with value 233 is é in Latin-1, but something else entirely in code page 437.
On toolz.dev I show the ISO 8859-1 (Latin-1) assignment for codes 160–255, because it is a real published standard and it is the basis of the original HTML character set - which means the named HTML entities line up. Codes 128–159 in Latin-1 are a second block of control characters (the "C1" controls), so the tool labels them as such rather than pretending they're printable.
The practical lesson: when someone says "extended ASCII," always ask which one. A mismatched code page is the classic cause of the é mojibake you see when a UTF-8 file is read as Latin-1, or the missing-glyph boxes when the reverse happens. Understanding data privacy and how tools handle your text is one concern; understanding how bytes map to characters is the other half of never being surprised by garbled text again.
Why do uppercase and lowercase differ by exactly 32?
This is my favourite piece of ASCII design, because it's not an accident - it's engineering. The layout was chosen so that a letter's uppercase and lowercase forms differ only in bit 5, which has the value 32. A is 65 (binary 01000001); a is 97 (binary 01100001). The only difference is that single bit.
That decision means a program can change case with one bitwise operation instead of a lookup table. To uppercase a lowercase letter, clear bit 5 (code & ~32); to lowercase an uppercase one, set it (code | 32); to swap case either way, flip it (code ^ 32). Decades of string libraries were built on that trick before Unicode's more complex case rules made it unsafe for anything beyond plain ASCII. When you browse the table and notice that every uppercase letter sits precisely 32 below its lowercase twin, you're looking at a decision made in the 1960s that still shapes how software is written.
How do I convert between characters, decimal, hex, and binary?
Every ASCII code has four common representations, and moving between them is a routine part of low-level work. Here's how they relate for the letter H:
| Representation | Value for H |
Where you'll see it |
|---|---|---|
| Character | H |
Normal text |
| Decimal | 72 | String.fromCharCode(72), chr(72) |
| Hexadecimal | 48 | Hex dumps, \x48, URL/percent encoding |
| Octal | 110 | Older Unix tools, \110 escapes |
| Binary | 01001000 | Bitwise operations, protocol design |
To spell a word from hex, take each pair of hex digits as one byte: 48 69 is 72 105 in decimal, which is Hi. To go the other way, look up each character's code. The ASCII Table does both directions - it shows all five columns for every code, and its search box accepts a character, a decimal number, a hex value (with or without a 0x prefix), an octal or binary string, or even an HTML entity name, so typing &, 38, or amp all jump to the ampersand.
If you're routinely converting whole strings or working across number bases beyond ASCII, the Binary Translator and the Number Base Converter are the companion tools I reach for. The ASCII table is the reference; those two are the workbenches.
What are ASCII control characters actually for?
The non-printing codes 0–31 (plus 127) feel like museum pieces, but several of them run your life daily.
Line feed (10) and carriage return (13) are the big two. On a teletype, carriage return moved the print head back to the left margin and line feed advanced the paper one line - two separate physical actions. That legacy is why Windows text files end lines with both (CRLF, 13 then 10), while Unix and macOS use just line feed (LF, 10). Nearly every "why is my file full of ^M characters?" bug traces back to this split. My CSV disaster from the intro was exactly this.
Horizontal tab (9) is the tab character - a single byte that editors render as several spaces. Null (0) terminates strings in C and marks "no data" in countless formats. Escape (27) introduces the control sequences that move your cursor and colour your terminal. Bell (7) once rang an actual bell; now it beeps or flashes your terminal window.
The reason a good table names these codes matters: when you find a byte 27 sitting in your data, "ESC - Escape" tells you instantly that you're looking at a terminal control sequence, not corrupt text. A raw number would leave you guessing.
How does ASCII relate to HTML entities and safe escaping?
If you write for the web - and building a solid developer toolkit means you will - a handful of ASCII characters need escaping so the browser doesn't misread them as markup. The less-than sign < (60), greater-than > (62), ampersand & (38), and double quote " (34) are the dangerous four. Left raw inside HTML they can break your page or open an injection hole; written as entities (<, >, &, ") they render as literal characters.
Every code also has a numeric HTML entity in the form &#code;, so even a character with no named entity can always be written safely. The ASCII table lists the named entity where one exists and the numeric form otherwise, and clicking the HTML column copies it straight to your clipboard. When you need to encode or decode a whole block of markup rather than look up a single character, the HTML Entities tool handles the batch job. For a deeper tour of the encoding utilities I use day to day, the coding tools guide walks through the whole set.
Is the ASCII table the same as Unicode?
No, but they're deliberately compatible, and the relationship is worth getting straight. Unicode is a vastly larger standard - over a million possible code points, covering every writing system plus symbols and emoji. ASCII, with its 128 codes, is a tiny subset. What makes them play nicely together is that Unicode's first 128 code points are defined to be identical to ASCII, and UTF-8 encodes exactly those 128 as single bytes with their ASCII values.
The consequence is elegant: any valid ASCII file is automatically a valid UTF-8 file. You never have to convert plain English text between the two. The moment you step beyond code 127 - an accented letter, a curly quote, an emoji - you leave ASCII behind and you're firmly in multi-byte Unicode territory, where one character may occupy two, three, or four bytes. The toolz.dev ASCII table covers the ASCII and Latin-1 ranges directly, and its text encoder reports the Unicode code point for any character you paste beyond them, so you can see exactly where ASCII ends and Unicode takes over.
Frequently asked questions
What is ASCII?
ASCII (American Standard Code for Information Interchange) is a character-encoding standard that maps letters, digits, punctuation, and control signals to the numbers 0–127. It was standardised as ANSI X3.4 in 1963 and remains the foundation of modern text encodings, including UTF-8, whose first 128 code points are identical to ASCII.
What is the ASCII value of "A"?
The uppercase letter "A" has the ASCII value 65 (hex 41, octal 101, binary 01000001). Lowercase "a" is 97 - exactly 32 higher - which is why flipping bit 5 switches a letter between uppercase and lowercase.
What is the difference between ASCII and extended ASCII?
Standard ASCII uses 7 bits and defines 128 codes (0–127). "Extended ASCII" uses the eighth bit to add another 128 codes (128–255) for accented letters, symbols, and box-drawing characters. There is no single extended ASCII - different code pages assign the upper half differently. This table shows the ISO 8859-1 (Latin-1) assignment, the basis of the Latin-1 HTML character set.
What are ASCII control characters?
Codes 0–31 and 127 are non-printing control characters that carry instructions rather than visible glyphs. Common ones include line feed (10), carriage return (13), horizontal tab (9), escape (27), and null (0). They originally controlled teletype machines and still terminate lines, delimit fields, and drive terminal escape sequences today.
How do I convert hex to ASCII?
Each pair of hex digits represents one byte, which maps to one ASCII code. Hex 48 is 72 in decimal, which is "H"; hex 69 is 105, which is "i" - so 48 69 spells "Hi". Search the ASCII table by the hex value (with or without a 0x prefix) to find the matching character instantly.
Why does uppercase differ from lowercase by 32 in ASCII?
ASCII was laid out so that the only difference between a letter's uppercase and lowercase forms is bit 5 (the value 32). "A" is 65 and "a" is 97; "Z" is 90 and "z" is 122. This deliberate design lets programs change case with a single bitwise operation rather than a lookup table.
Is the ASCII table the same as Unicode?
Not the same, but compatible. Unicode is a far larger standard covering more than a million code points across every writing system. Its first 128 code points are identical to ASCII, and UTF-8 encodes them as single bytes, so valid ASCII text is also valid UTF-8. The ASCII table covers the ASCII and Latin-1 ranges; its encoder reports Unicode code points for characters beyond them.
Is my text private when I use the ASCII Table?
Yes. The whole table is generated in your browser in plain JavaScript, and any text you paste into the encoder is processed locally - it is never uploaded, logged, or stored, and the tool keeps working with no network connection once the page has loaded.
Written by Liton, builder of toolz.dev, WP Adminify, and a long line of Laravel and React projects that all, sooner or later, came down to getting the bytes right.
