{# canonical_base is the OWNING tenant's origin: all 16 Peasy domains serve the same catalogue, so a page rendered by a non-owner points its canonical at the owner instead of competing with it. Falls back to this site for static/self-owned pages. #}
🍋
Menu

UTF-8 vs ASCII

ASCII encodes 128 characters in seven bits; UTF-8 encodes the whole of Unicode — 1,114,112 code points — in one to four bytes per character. They are not rivals so much as one containing the other: UTF-8 was designed so that the code points U+0000 through U+007F are written as the same single bytes ASCII uses, which makes every valid ASCII file already a valid UTF-8 file, byte for byte. The practical question is therefore not which to choose for new work — RFC 3629 and the WHATWG Encoding Standard settle that — but how to read the distinction in systems that still declare ASCII.

At a glance

  UTF-8 ASCII
Specification RFC 3629 (Unicode) ANSI X3.4-1968 (US-ASCII)
Characters 1,114,112 code points 128 code points
Bytes per character 1 to 4, variable 1 (7 bits used)
Covers Every writing system in Unicode, plus emoji and symbols Latin letters, digits, punctuation, 33 control codes
Byte 0x41 Latin capital "A" (U+0041) Latin capital "A"
Byte range used 0x00-0xF4 (multi-byte sequences use 0x80-0xF4) 0x00-0x7F only
Status for new content Required by the WHATWG Encoding Standard; HTML5 default Legacy; valid but a strict subset

Key differences

  • UTF-8 is a strict superset. An ASCII file needs no conversion to be read as UTF-8, which is why the migration path across the web was gradual rather than a flag day.
  • The byte length depends on the code point: one byte to U+007F, two to U+07FF, three to U+FFFF, four to U+10FFFF. An English document costs the same in UTF-8 as in ASCII; a Japanese document costs roughly three bytes per character.
  • ASCII cannot represent characters outside its 128 slots at all — é, 中 and emoji have no ASCII form, which is what produces mojibake when a UTF-8 byte stream is decoded as a single-byte legacy encoding.
  • A UTF-8 byte order mark (EF BB BF) is permitted but not recommended by the Unicode standard; it is the leading cause of an unexpected character before the first field of a CSV or the opening tag of a document.
  • The high bit distinguishes them: any byte with its top bit set means the file is not ASCII, which is the check most encoding detectors start from.

When to choose which

UTF-8

  • All new documents, APIs, source files and databases.
  • Any content that may ever carry a name, currency symbol or language outside basic Latin.
  • Interchange with web standards, which assume UTF-8 unless told otherwise.

ASCII

  • Interfacing with hardware or protocols that specify seven-bit transport.
  • Fixed-width legacy record formats where byte offsets are part of the contract.
  • Identifiers deliberately restricted to a portable character set, such as DNS labels or environment variable names.

Frequently asked questions

Is ASCII a subset of UTF-8?

Yes. UTF-8 encodes U+0000 through U+007F as the identical single bytes ASCII uses, so any ASCII file is already valid UTF-8 without conversion.

How many bytes does a character take in UTF-8?

One byte up to U+007F, two up to U+07FF, three up to U+FFFF and four up to U+10FFFF. Latin text is one byte per character; most CJK characters are three.

What causes mojibake?

Decoding bytes with an encoding other than the one used to write them. UTF-8 bytes read as a single-byte legacy encoding produce the characteristic runs of accented capitals.

Should a UTF-8 file include a byte order mark?

Generally not. UTF-8 has no byte order to signal, and the Unicode standard does not recommend the mark. Some Windows tooling still writes it, so parsers commonly strip a leading EF BB BF.

How can I tell whether a file is plain ASCII?

Check whether any byte has its high bit set. If every byte is 0x00-0x7F the file is ASCII, and therefore also UTF-8.

Related reference