ASCII table

How ASCII encodes text

ASCII assigns a number to each character, and that number is what a computer actually stores. The encoding uses seven bits, which gives 128 possible values, numbered 0 to 127. Thirty-three of those are control codes that instruct a device rather than print anything; the remaining ninety-five are the printable characters — space, punctuation, the ten digits and the unaccented Latin alphabet in both cases.

The layout is not arbitrary, and noticing the structure makes the table far easier to remember. Uppercase letters run from 65 to 90 and lowercase from 97 to 122, a gap of exactly 32 — one bit — so changing case means flipping bit 6 and nothing else. The digits occupy 48 to 57, which in hexadecimal is 0x30 to 0x39, so the last hex digit is the numeral: mask off the high bits of the character '7' and you get the number 7. Control codes sit first precisely so that everything printable begins at a clean boundary, with space at 32.

The history of ASCII

ASCII was published in 1963 by the American Standards Association as ASA X3.4, the work of the X3.2 subcommittee on which IBM's Bob Bemer was a leading figure — he is often called the father of ASCII and is credited with getting the escape character into the standard. A significant revision in 1967 produced the layout still in use, and the 1986 edition, ANSI X3.4-1986, is the version usually cited today.

The control codes make much more sense once you know the machinery they were written for. These were teleprinters: BEL at code 7 rang a physical bell to get the operator's attention, BS moved the print head back one position so a character could be struck over, and the separation of carriage return from line feed existed because they were two distinct mechanical actions — return the carriage to the left margin, then advance the paper by one line. That distinction is the direct ancestor of the line-ending disagreement between Windows, which still writes both, and Unix, which writes only the line feed.

ASCII was not universal at first. IBM's mainframes used EBCDIC, an entirely different and incompatible encoding, and moving data between the two worlds was a standing nuisance for decades. What settled the matter was Unicode: when UTF-8 was designed in 1992, Ken Thompson and Rob Pike made the first 128 code points identical to ASCII and encoded them as single bytes with the same values. Every ASCII file became a valid UTF-8 file overnight, and that backward compatibility is a large part of why UTF-8 now encodes almost the entire web.

Extended ASCII is not one thing

Once hardware settled on eight-bit bytes, the spare bit left room for another 128 characters above 127 — and everyone filled that space differently. IBM's code page 437 put box-drawing characters and Greek letters there for the original PC. ISO 8859-1, usually called Latin-1, used it for Western European accented letters. Microsoft's Windows-1252 is Latin-1 with the unused 128–159 range filled in with curly quotes, dashes, the euro sign and similar typographic characters.

The consequence is that a byte above 127 has no single meaning. The value 233 is é in Latin-1 and Windows-1252, but Θ in code page 437. This is the root cause of the classic mojibake you still meet today — the "’" that appears where an apostrophe should be is UTF-8 bytes being read as Windows-1252. The table above shows the Windows-1252 interpretation because it is the one most often encountered on the web, and gives the Unicode code point for each so there is no ambiguity about which character is meant.

Where ASCII codes are still worth knowing

Looking up a code is a routine step in several everyday jobs. Debugging data that will not parse usually means finding a stray control character or a non-ASCII byte where plain text was expected. Writing or reading regular expressions often means working in character ranges, and knowing that digits are 48–57 and uppercase 65–90 explains why [A-Za-z0-9] is written the way it is. Escaping characters for HTML, URLs or a shell depends on knowing precisely which character you have. And anyone working with serial devices, terminal escape sequences or fixed-width file formats meets the control codes directly.

Related conversions live in their own tools: binary to text converts whole messages between 8-bit binary and readable text, the base converter moves any number between binary, octal, decimal and hexadecimal, and HTML encoder / decoder converts characters to and from the entity codes shown in the table. For characters beyond ASCII, see special characters & symbols, and for the invisible ones that break parsing, the invisible character detector.

Frequently asked questions