Text Encodings Explained: UTF-8, ASCII, and Why Characters Break

Have you ever opened a text file and found strange characters where normal words should be? A sentence that should read “café” might appear as “café,” while quotation marks or accented letters may turn into symbols that seem completely unrelated to the original text.

This problem is often called mojibake. It happens when text is decoded using an encoding that does not match the encoding used to store or transmit it.

Text encodings determine how computers represent characters as bytes. When an application interprets those bytes incorrectly, the result can be garbled text, broken punctuation, or unreadable symbols.

Understanding ASCII, UTF-8, and other character encodings can help you diagnose these problems when working with websites, source code, CSV files, databases, emails, or downloaded documents. A text encoding tool such as 100 MultiView's Encodings tool can also help you inspect and compare text representations.

What Is a Text Encoding?

Computers store information as numbers. Text, however, consists of characters such as letters, digits, punctuation marks, and symbols. A text encoding defines how characters are represented as bytes so that software can store, transfer, and interpret text.

Consider the word:

Hello

In ASCII, each character has a numeric value. The letter H, for example, has the decimal value 72, represented by the byte 01001000 in binary.

When software reads the bytes using the correct encoding, it reconstructs the intended characters. But if the software uses an incompatible encoding, the same bytes may produce different characters or replacement symbols.

This is why a file can contain valid data at the byte level and still display the wrong text.

What Is ASCII?

ASCII stands for American Standard Code for Information Interchange. It is an older character encoding designed primarily for English letters, digits, punctuation, and control characters.

Standard ASCII uses seven bits per character, providing 128 possible values, numbered from 0 through 127.

These values include:

• Uppercase letters from A to Z
• Lowercase letters from a to z
• Digits from 0 to 9
• Common punctuation marks
• Control characters, such as line feed

For example, the word Cat uses these ASCII decimal values:

ASCII works well for basic English text, but it cannot directly represent many characters used in other languages.

Characters such as ñ, é, 中, and € are outside standard ASCII. Other encodings were developed to support additional characters, but using different encoding systems created compatibility problems.

What Is UTF-8?

UTF-8 is a Unicode encoding that represents Unicode characters using one to four bytes. Unicode provides a common system for identifying characters from many writing systems, including Latin, Arabic, Chinese, Japanese, and numerous others.

UTF-8 is widely used on the web because it supports a broad range of characters while remaining compatible with standard ASCII for the first 128 values.

For example:

These byte sequences are different because UTF-8 uses variable-length encoding. A basic English letter usually takes one byte, while many other characters take two, three, or four bytes.

The important point is that UTF-8 is not a separate character collection from Unicode. Unicode defines characters and their code points; UTF-8 defines one way to encode those code points as bytes.

ASCII vs. UTF-8: What Is the Difference?

ASCII and UTF-8 are closely related, but they serve different needs.

Because UTF-8 preserves the ASCII byte values for the basic ASCII range, ordinary English text often looks identical in both. Problems become more noticeable when text contains characters outside that range.

What Is Mojibake?

Mojibake is garbled text produced when bytes are interpreted using the wrong character encoding. The original information may still be present, but the software displays characters that do not match the intended text.

Here is a common example:

These examples can occur when UTF-8 bytes are incorrectly interpreted as Windows-1252 or a similar legacy encoding. The exact result depends on the bytes and the encoding used by the application.

Why does café become café?

The character é is encoded in UTF-8 as two bytes:

• C3
• A9

If those bytes are mistakenly decoded as Windows-1252, they correspond to characters that display as Ã and ©. As a result, café becomes café.

The original é has not necessarily been deleted. Instead, the program has interpreted its encoded bytes incorrectly.

This is one of the most recognizable patterns of mojibake.

Common Reasons Text Becomes Garbled

1. A file is opened using the wrong encoding

A text editor might assume a file uses one encoding when the file was saved in another. If the application guesses incorrectly, accented letters and punctuation can display incorrectly.

For example, a file saved as UTF-8 might be opened as Windows-1252. English words may look normal, while special characters become garbled.

2. A website declares the wrong character set

Web browsers use information from the document and its HTTP response to determine how text should be decoded. If the declared character set does not match the actual bytes, the page can display broken characters.

For an HTML page that uses UTF-8, a common declaration is:

<meta charset="UTF-8">

The declaration should match the encoding actually used to save the document. Adding this tag alone will not repair a file whose contents were already corrupted.

3. Text passes through multiple systems

A message might travel through a database, export tool, email client, and spreadsheet application. If one stage decodes the text incorrectly or saves it using an unexpected encoding, characters may become garbled.

For example, a name containing accented letters could display correctly in a database but appear broken after being exported to a CSV file and opened in another application.

4. Data is decoded more than once

Repeatedly interpreting already-decoded text as though it were still encoded bytes can produce additional corruption.

For example:

café → café → café

This pattern can indicate that a decoding mistake has happened more than once. However, the exact history should be confirmed rather than inferred from appearance alone.

5. Unsupported characters are replaced during conversion

Some encodings cannot represent every character in the original text. When software converts text to a limited encoding, unsupported characters may be replaced with question marks or replacement symbols.

For example, converting text containing emoji into an encoding that cannot represent them may produce ? or another placeholder.

This is different from a simple decoding mismatch: if the original characters were replaced and the original data was discarded, changing the encoding later may not recover them.

How to Diagnose Garbled Text

If you see unusual characters in a document or webpage, use a systematic approach instead of repeatedly changing settings at random.

Step 1: Keep a copy of the original

Before attempting repairs, duplicate the file or preserve the original text. Some conversions can permanently replace characters, making recovery harder.

Step 2: Identify where the problem occurs

Ask yourself:

• Does the text look wrong in one application but correct in another?
• Does the problem affect only accented characters and punctuation?
• Is the file downloaded from a website, exported from a database, or generated by a script?
• Does the problem affect every character or only certain symbols?

If the text looks correct in one program but wrong in another, the issue may be how the second program interprets the data.

Step 3: Check the expected encoding

For a website, inspect the HTTP Content-Type header and the HTML character-set declaration.

For a text file, check the editor's encoding information. If you control the software that generated the file, confirm how it encoded the output.

UTF-8 is a good default for modern applications, but do not assume every existing file is UTF-8.

Step 4: Test a small sample

Choose a short portion of text containing a recognizable problem, such as café.

Try interpreting the original bytes using the likely encoding, or use an encoding inspection tool to compare candidate interpretations. If the sample becomes café, you may have identified the mismatch.

Do not simply convert the garbled visible text to UTF-8 without understanding what happened. The characters currently displayed may already be the result of a previous incorrect decoding step.

Step 5: Fix the source of the mismatch

Once you identify the cause, correct the relevant step:

• Open the file using its actual encoding.
• Save the original text as UTF-8 when appropriate.
• Make sure web pages declare the encoding they actually use.
• Configure database connections and exports consistently.
• Ensure applications decode bytes once using the intended encoding.

The best fix is to correct the earliest incorrect step, rather than repeatedly repairing the final display.

How to Fix Common Mojibake Examples

Example 1: café instead of café

Likely cause: UTF-8 bytes were decoded as Windows-1252 or a similar encoding.

What to try: If you have the original bytes, decode them as UTF-8. If you only have the garbled text, a carefully tested reverse transformation may work, provided the bytes have not been lost or replaced.

Example 2: € instead of €

Likely cause: The UTF-8 byte sequence for the euro symbol was interpreted using an incompatible encoding.

What to try: Check the source file or response encoding and verify that the euro symbol's UTF-8 bytes are being decoded as UTF-8.

Example 3: Question marks replacing characters

Likely cause: A conversion or export may have replaced characters that the destination encoding could not represent.

What to try: Return to the original source if possible. If the characters were permanently replaced with question marks, the exact original characters may not be recoverable from the damaged text alone.

Example 4: Black diamonds with question marks

A character may appear as , often displayed as a black diamond with a question mark. This is the Unicode replacement character.

Likely cause: A decoder encountered a byte sequence it could not interpret as valid text under the selected encoding.

What to try: Examine the original bytes and determine which encoding was intended. If the original byte sequence is still available, correct decoding may recover the text. If the data was already replaced and discarded, recovery may be impossible.

How Text Encodings Work on Websites

Websites frequently exchange text through HTML documents, JavaScript, APIs, and databases. Consistent encoding settings help prevent characters from breaking as they move between systems.

For modern websites, UTF-8 is generally the recommended choice.

An HTML page can declare UTF-8 near the beginning of its document:

<meta charset="UTF-8">

A server can also indicate the character set in its HTTP response headers, for example:

Content-Type: text/html; charset=UTF-8

The actual bytes must match these declarations. If the response says UTF-8 but the content was encoded differently, a declaration alone cannot solve the problem.

When working with JSON, the standard encoding for interoperable JSON exchanged between systems is UTF-8. Developers should also ensure that databases, application code, and exports preserve text correctly from end to end.

Can Changing the Font Fix Mojibake?

Usually, no.

A font controls how supported characters are drawn on the screen. An encoding controls how bytes are interpreted as characters. These are different parts of text processing.

If a font does not contain a character, the application may show a blank box or a fallback symbol. If the text displays café instead of café, the problem is more likely related to decoding than to the font itself.

A useful distinction is:

• Wrong characters: Investigate the encoding and the original bytes.
• Missing glyphs or boxes: Investigate font support and character coverage.
• Replacement symbols: Investigate whether the original byte sequence was invalid, unsupported, or already damaged.

Changing fonts may help with missing glyphs, but it will not generally repair text that has been decoded incorrectly.

If you are adjusting text appearance rather than troubleshooting encoding problems, explore our Font Sizes tool. Remember that changing font size will not repair incorrectly decoded text.

Frequently Asked Questions

Is UTF-8 the same as Unicode?

No. Unicode assigns code points to characters, while UTF-8 is one way of encoding those code points as bytes. UTF-16 and UTF-32 are other Unicode encoding forms.

Is ASCII a subset of UTF-8?

Yes. Standard ASCII values from 0 to 127 use the same byte values in UTF-8. This is why ordinary English text often looks the same in both encodings.

Why does mojibake often affect accented letters first?

Basic English letters use the shared ASCII range and are often decoded correctly even when the encoding is wrong. Many accented letters and symbols use multiple bytes in UTF-8, making mismatches more visible.

Can mojibake always be fixed?

No. If the original bytes remain available and were simply decoded incorrectly, recovery is often possible. If characters were replaced, deleted, or overwritten during conversion, the original text may be impossible to reconstruct exactly.

Should every text file be converted to UTF-8?

UTF-8 is a strong default for new text files and modern applications. However, convert existing files carefully: identify their current encoding first, preserve a backup, and verify the result after conversion.

What is the difference between mojibake and a missing character?

Mojibake means the text is interpreted as the wrong characters. A missing glyph occurs when the intended character exists in the text but cannot be displayed by the chosen font or rendering system. The two problems can look similar, but they have different causes.

Final Thoughts

Text encodings make it possible for computers to store and exchange writing from many languages. ASCII supports a limited set of basic characters, while UTF-8 provides a widely compatible way to represent Unicode text.

When characters break, the cause is often a mismatch between how text was encoded and how it was decoded. Recognizing patterns such as café, checking the source encoding, and preserving the original bytes can help you diagnose the issue without making the damage worse.

For practical experiments, visit 100 MultiView's Encodings tool to explore text encoding concepts and compare how text can be represented. When troubleshooting real files or website data, always verify the actual encoding and keep an untouched copy of the original.

Visit the 100 MultiView homepage to explore more browser-based tools.