What Is ASCII? Converting Text to Character Codes

Computers only store numbers, so every letter you read on a screen is really a number behind the scenes. ASCII is the scheme that first standardised which number stands for which character: capital A is 65, lowercase a is 97, the digit 0 is 48. Converting text to these codes reveals the numeric reality underneath writing, and the Text to ASCII tool does it in your browser. This article explains what ASCII is, what it covers, and how it grew into the Unicode system that handles every language and emoji today.

Understanding character codes clears up a surprising number of everyday mysteries, why text sometimes turns into garbled symbols, why an emoji counts as more than one character, and how encoding actually works.

How computers turn letters into numbers

A computer's memory holds numbers, so to store text it needs an agreed mapping between characters and numbers, a character encoding. ASCII, the American Standard Code for Information Interchange, was that agreement: a table assigning a number from 0 to 127 to each of the English letters, digits, punctuation marks and a set of control codes. Because everyone agreed on the same table, a file written on one machine could be read correctly on another. When you convert text to ASCII, you are simply looking up each character's number in this table.

What the ASCII table contains

ASCII's 128 codes are organised into meaningful ranges:

• 0–31: control characters, non-printing codes like tab, newline and carriage return that control formatting and devices.
• 32–47, 58–64, 91–96, 123–126: punctuation and symbols, including the space at 32.
• 48–57: the digits 0 through 9.
• 65–90: uppercase A through Z.
• 97–122: lowercase a through z.

A neat consequence of this layout is that uppercase and lowercase letters are exactly 32 apart, A is 65, a is 97, which is why converting case is such a simple operation for a computer. Little regularities like this were deliberate design choices that made early text processing efficient.

From ASCII to Unicode

ASCII was built for English and quickly proved too small for a global, connected world. It had no way to represent accented letters, non-Latin scripts, or the countless other symbols people needed. Unicode was created to fix this: a vastly larger standard that assigns a unique number, called a code point, to every character in every writing system, plus symbols and emoji, over a hundred thousand of them. Crucially, Unicode was designed so that its first 128 code points are identical to ASCII, which means ASCII text is automatically valid Unicode. ASCII did not disappear; it became the foundation that Unicode built upon.

How Unicode is actually stored: UTF-8

A code point is an abstract number; UTF-8 is the near-universal way those numbers are turned into bytes for storage and transmission. Its clever design is that ASCII characters take exactly one byte each, so plain English text is byte-for-byte identical to old ASCII, while other characters take two, three or four bytes as needed. This backward compatibility is a big reason UTF-8 won out and now encodes the overwhelming majority of the web. It also explains the earlier puzzle: a character outside the ASCII range occupies several bytes, which is why it can count as more than one unit against certain limits.

Why character codes matter in practice

Knowing about character codes demystifies real problems. Garbled text, where accented letters turn into strange symbol pairs, is almost always an encoding mismatch, where text saved as UTF-8 is read as something else. Character-code awareness also underpins related encodings a developer meets daily: Base64 and URL encoding both operate on the byte values that character encodings produce, and the numeric codes themselves connect to base conversion, since a character's code is often shown in hex via a number base converter.

Debugging garbled text and encoding mismatches

One of the most practical payoffs of understanding character codes is being able to diagnose "mojibake", the garbled text where a word like café shows up as café or a string dissolves into question marks and boxes. This almost always happens because text was written in one encoding and read in another: a file saved as UTF-8, where an accented character occupies several bytes, is misread by software assuming an older single-byte encoding, so each byte is shown as a separate wrong character. Recognising the pattern tells you immediately that the data is fine and only the interpretation is wrong.

The fix is to make the writer and reader agree on the encoding, and in practice that almost always means using UTF-8 everywhere, in your files, your database, your web page's declared charset, and your API responses. Because UTF-8 is backward-compatible with ASCII, plain English text is unaffected, and everything else is handled correctly as long as both ends agree. When you convert text to its character codes and see exactly which numbers and how many bytes each character occupies, these encoding problems stop being mysterious and become obvious: you can see that an accented letter is multiple bytes, understand why a mismatched reader mangles it, and know that standardising on UTF-8 is the cure. That same byte-level clarity underpins why length limits sometimes count a single emoji as several characters, and why encodings like Base64 and URL-encoding operate on bytes rather than letters. Character codes are the layer beneath all of it.

In summary, ASCII was the original agreement that let computers store English text as numbers, mapping each character to a code from 0 to 127. Unicode extended that idea to every language and emoji while keeping ASCII as its foundation, and UTF-8 stores it all efficiently with ASCII as a one-byte special case. Convert text to its codes once and the hidden numeric layer beneath all writing, and the reason text occasionally garbles or miscounts, becomes clear.