What is ASCII? How computers turn letters into numbers

ASCII, the American Standard Code for Information Interchange, is a character encoding: a table that gives each of 128 characters a number from 0 to 127, so that text can be stored and sent as numbers. The capital letter H is 72, the small letter i is 105, a space is 32. First published in 1963, it covers English letters, digits, punctuation and control codes, and it lives on as the first 128 characters of Unicode.

In short

• Computers store only numbers, so text needs an agreed table of which number means which character. ASCII, from 1963, became the one computers shared.
• ASCII's 128 codes fit in 7 bits, enough for English but not for accented letters, other alphabets or emoji.
• Unicode gives every character in every writing system its own number, and UTF-8 stores those numbers in 1 to 4 bytes, using exactly ASCII's bytes for ASCII's characters.

Why do computers need a character encoding?

A computer's memory holds bits, 0s and 1s, which can stand for numbers, as the note on how binary works explains. Letters have no natural number. To store the word "Hi", everyone involved has to agree on a code: which number means H, which means i. The agreed table is a character encoding, and a file of text is just a list of those numbers.

Before ASCII, manufacturers each had their own codes, so text from one company's machine could come out as nonsense on another's. Work on a common standard began in May 1961, when the IBM engineer Bob Bemer submitted a proposal to the American Standards Association. The first edition was published in 1963, a major revision followed in 1967, and the last in 1986 (Wikipedia). In 1969 an early internet document, RFC 20, proposed standard 7-bit ASCII as the format for text sent between computers on the ARPANET, and that choice still shapes email and other protocols today.

How is ASCII laid out?

ASCII's 128 codes fit in 7 bits, since 2⁷ = 128. They split into two kinds:

Codes	What they are	Examples
0 to 31, and 127	33 control codes, instructions rather than characters	9 is a tab, 10 a new line, 13 a carriage return, 127 delete
32 to 126	95 printable characters	32 space, 48 to 57 the digits 0 to 9, 65 to 90 A to Z, 97 to 122 a to z

The table was laid out with care. The digits 0 to 9 sit at 48 to 57, so a digit's value is its code minus 48. Capital letters run 65 to 90 and small letters 97 to 122, so every small letter is its capital plus 32, which in binary is a single bit: A is 1000001 and a is 1100001. That one-bit difference made it simple to build keyboards and printers and to match text regardless of case. Alphabetical order is also numerical order, which made sorting easy.

How does "Hi" become bits? A worked example

Follow the two letters from keyboard to storage.

1. Look up each character. In the ASCII table, H is 72 and i is 105.
2. Write each number in binary. 72 is 64 + 8, which is 1001000. 105 is 64 + 32 + 8 + 1, which is 1101001.
3. Pad to a byte. Computers store characters in 8-bit bytes, so a 0 goes on the front: 01001000 and 01101001.
4. Store or send them. "Hi" is now 16 bits, 2 bytes, which in hexadecimal are written 48 69.

Reading it back runs the steps in reverse: split the bits into bytes, turn each byte into a number, look the number up. Nothing in the bits says "this is text": the same two bytes could be the number 18,537 or part of a photo. Software has to know, or guess, which encoding was used. ASCII needs only 7 bits, but storing each character in a full byte of 8, the unit bits vs bytes lays out, made one character per byte the basic unit of plain text.

Why wasn't ASCII enough?

Because the world doesn't write in 95 characters. ASCII has no é, ñ or ß, no Greek, Cyrillic, Arabic, Hebrew or Devanagari letters, and none of the thousands of characters needed for Chinese and Japanese. Since computers stored characters in 8-bit bytes anyway, the obvious fix was to use the spare 128 codes from 128 to 255. Many groups did, in different ways: one table for Western European languages, another for Cyrillic, another for Greek, and others for Japanese that used two bytes per character. These code pages were often loosely called "extended ASCII", but there was never one extended ASCII.

The result was the old problem back again. A file written with one code page and read with another came out wrong, and a document could not easily mix, say, Russian and Greek.

How do Unicode and UTF-8 fix it?

Unicode separates two jobs that ASCII had combined. First, it gives every character its own number, called a code point and written U+ followed by hexadecimal digits: A is U+0041, é is U+00E9, the grinning face emoji is U+1F600. There is room for over a million code points. Version 18.0 of the standard, released on 16 September 2026, defines 172,808 characters, according to the Unicode Consortium. The first 128 code points are ASCII, in the same order.

Second, an encoding turns those numbers into bytes. The dominant one, UTF-8, was designed by Ken Thompson and Rob Pike of Bell Labs in September 1992 (Wikipedia) and is specified in RFC 3629. It uses 1 to 4 bytes per character:

Character	Code point	UTF-8 bytes (hex)	Bytes
H	U+0048	48	1
é	U+00E9	C3 A9	2
€	U+20AC	E2 82 AC	3
Grinning face emoji	U+1F600	F0 9F 98 80	4

The design is what made UTF-8 win. Any character in ASCII is stored as the same single byte ASCII uses, so every ASCII file is already valid UTF-8. Every byte of a longer character starts with a 1 bit, so it can never be mistaken for an ASCII character. And the first byte says how many follow: é's first byte, C3, is 11000011 in binary, and its two leading 1s announce a 2-byte character. Reading UTF-8 back is a short algorithm that can start anywhere in a stream and find where the next character begins. By 5 November 2026, W3Techs found UTF-8 on 99.1% of websites whose encoding it could identify. A web page states its encoding near the top of its HTML, so the browser knows how to read it.

What is mojibake, and why does text get garbled?

Mojibake, from the Japanese for "character transformation", is the garbled text you get when bytes are decoded with the wrong encoding. The commonest kind in English is UTF-8 read as an old Western European code page.

Take "café". In UTF-8, é is two bytes, C3 and A9. Software that wrongly assumes the Windows-1252 code page reads each byte as its own character: C3 there is à and A9 is ©. So "café" comes out as "café". An emoji, four bytes, turns into four junk characters. The fix is never to edit the junk but to read the original bytes again with the right encoding.

Three habits prevent it: save text as UTF-8, declare the encoding where the format allows it (HTML, email headers, databases), and when text looks garbled with à or †in it, suspect UTF-8 decoded as something else. Programmers meet this daily, which is why almost every modern programming language now treats text as Unicode by default.

Check yourself

• Without looking back, turn the word "Ok" into ASCII numbers and then into two bytes of binary, given that O is 79 and k is 107.
• Why can every ASCII file be read as UTF-8 without any change?
• What happened, byte by byte, when "café" turned into "café"?

Sources

• ASCII — Wikipedia
• RFC 20: ASCII format for Network Interchange — Vint Cerf, Network Working Group, 1969
• Unicode 18.0.0 — Unicode Consortium, 2026
• RFC 3629: UTF-8, a transformation format of ISO 10646 — Internet Engineering Task Force, 2003
• UTF-8 — Wikipedia
• Usage statistics of character encodings for websites — W3Techs, 2026