What Is the ASCII Code?

ASCII stands for American Standard Code for Information Interchange. The standard was published in 1963 as ASA X3.4-1963, drafted by a committee of the American Standards Association, the predecessor of today's ANSI. Its original purpose had nothing to do with web pages: it let teletypes, computers and telecommunication equipment from different manufacturers exchange text without dropping a single character along the way.

The core idea is simple. Every character gets a number between 0 and 127, representable in 7 bits. The first 32 numbers, 0 through 31, are control characters: line feed, carriage return and similar instructions aimed at the receiving device, not symbols meant to show up on screen. From 32 to 126 come upper and lowercase letters, the digits 0 through 9, and basic English punctuation. Number 127 is DEL, a deletion character inherited from the era of punched paper tape.

The 1963 version didn't even include lowercase letters; those arrived with the 1967 revision. The last substantive update landed in 1986, as ANSI X3.4-1986, and the set of 128 characters has stayed fixed ever since. That stability is exactly why it still matters in technical SEO sixty years later: none of those 128 numbers has changed meaning since.

The three terms get mixed up in everyday technical conversation, even though they aren't interchangeable. ASCII is a closed set of 128 characters. Unicode is a much broader standard that assigns a unique number to virtually every character humans write with, over 149,000 assigned characters as of its 2025 release. UTF-8 is an encoding: the specific way those numbers get turned into bytes for storage or transmission.

The point that rarely gets explained well is backward compatibility. UTF-8 was designed so that the first 128 Unicode characters, exactly the ones ASCII already covers, take up a single byte with the same value they'd have in plain ASCII. An ASCII text file is, without any change at all, a valid UTF-8 file. The reverse isn't true: a UTF-8 file with an accented letter or an emoji stops being ASCII the moment that character shows up.

An ASCII character takes up 7 bits, but almost no modern system moves data in 7-bit units; everything works in 8-bit bytes. That spare eighth bit, left undefined in the original specification, became the source of a lot of encoding headaches in the 1990s. Different vendors used it for 128 extra characters, usually accented vowels and letters from other languages, each with its own table: ISO 8859-1 (Latin-1) across much of Western Europe, Windows-1252 on Windows PCs, other code pages elsewhere.

When text moved between two systems that didn't agree on which table to use, the result was mojibake: an accented letter turning into a meaningless symbol, a character showing up as a blank box, text that simply couldn't be read. Unicode and UTF-8 exist precisely to end that dependency on whichever table a given machine happened to use.

When a non-ASCII character has to travel through a channel that only accepts ASCII, as still happens in a URL or an email header, percent-encoding takes over: the character first gets converted to UTF-8 bytes, and each byte is written as a % followed by two hexadecimal digits, using nothing but ASCII characters to represent something that wasn't ASCII to begin with. A plain-text configuration file like a site's robots.txt is still recommended to stay in ASCII or unmarked UTF-8, so any crawler reads it without ambiguity.

ASCII still matters in 2026 for a concrete reason: several pieces of web infrastructure still expect that format, or clearly prefer it. Google says so explicitly in its documentation on URL structure: it recommends percent-encoding any character outside the ASCII range, and its "not recommended" example shows a URL with unencoded Arabic characters next to its encoded version.

The most practical case is a URL slug. One with accented characters doesn't break the page, but browsers and many systems end up displaying the percent-encoded version instead, unreadable for a human and less clear in a search result. That readability is also part of user experience the moment someone copies or shares the link by hand. If the accented URL and its encoded counterpart end up coexisting, two different addresses point at the same page, and that's when a canonical tag earns its keep, marking which version counts as the reference.

Outside the browser, email headers and plenty of legacy systems still expect plain ASCII, and a file name with special characters can behave differently depending on the operating system or server it gets uploaded to.

• Stick to unaccented letters, numbers and hyphens in every URL slug; avoid accented characters and spaces even when the content itself is in another language.
• Let the browser or server percent-encode any non-ASCII character rather than typing it directly into a link.
• Save plain-text files as UTF-8 without a BOM; it stays byte-for-byte compatible with ASCII for the first 128 characters.
• Name files you upload to a server (images, PDFs, stylesheets) without accented characters or symbols, to avoid inconsistent behavior across hosting systems.
• Keep robots.txt and other configuration files in plain ASCII, without special characters a crawler or server might misread.
• If an accented URL and its encoded version end up coexisting, mark the one you want indexed with a canonical tag instead of leaving the choice to search engines.

• Typing accented characters directly into a link instead of letting them get encoded, which creates two different addresses for the same content.
• Treating ASCII and Unicode as synonyms: ASCII covers 128 characters, Unicode covers over 149,000.
• Saving a file in an encoding other than UTF-8, such as Windows-1252, without declaring it, which produces mojibake when it's opened on another system.
• Sending email headers with non-ASCII characters without encoding them per the MIME standard, which leaves some mail clients displaying garbled text.
• Dropping special characters like checkmarks or arrows straight into a title or meta description without checking whether the search engine supports them, which sometimes shows a broken character in the snippet instead of the intended symbol.