HTML Guides for encoding

The < and > characters have special meaning in HTML — they signal the start and end of tags. When the parser encounters </>, it sees what looks like a closing tag with no element name, which is invalid in HTML. This sequence can appear in your markup for two main reasons:

1. Unescaped text content: You're trying to display the literal characters </> as visible text on the page (common in tutorials, documentation, or code snippets), but the browser interprets them as markup rather than content.
2. Mistyped end tag: You intended to write a proper closing tag like </p> or </div> but accidentally omitted the element name, leaving just </>.

This matters because browsers may silently discard the malformed tag or interpret it in unexpected ways, leading to broken layouts or missing content. Screen readers and other assistive technologies may also struggle with the resulting DOM structure. Properly escaping special characters and writing well-formed tags ensures consistent rendering across all browsers and devices.

To fix this, determine which scenario applies. If you want to display the literal text </>, replace < with < and > with >. If you meant to close an element, add the correct element name between </ and >.

Examples

Unescaped angle brackets in text content

This triggers the error because the parser sees </> as an invalid closing tag:

<!-- ❌ Bad: raw </> in text content -->

<p>In JSX, self-closing tags use the </> syntax.</p>

Escape the angle brackets using HTML character entities:

<!-- ✅ Good: properly escaped characters -->

<p>In JSX, self-closing tags use the &lt;/&gt; syntax.</p>

Mistyped closing tag with missing element name

This triggers the error because the closing tag has no name:

<!-- ❌ Bad: empty closing tag -->

<div class="container">

<p>Some content here.</p>

</>

Add the correct element name to the closing tag:

<!-- ✅ Good: proper closing tag -->

<div class="container">

<p>Some content here.</p>

</div>

Displaying code snippets with angle brackets

When writing about HTML or XML in your page content, all angle brackets in text must be escaped:

<!-- ❌ Bad: unescaped tags in text -->

<p>Use <strong> to make text bold and </strong> to close it.</p>

<!-- ✅ Good: escaped tags in text -->

<p>Use &lt;strong&gt; to make text bold and &lt;/strong&gt; to close it.</p>

Using the <code> element for inline code

Even inside <code> elements, angle brackets must still be escaped — the <code> element only changes visual presentation, it does not prevent HTML parsing:

<!-- ❌ Bad: unescaped inside <code> -->

<p>A React fragment looks like <code><></code> and <code></></code>.</p>

<!-- ✅ Good: escaped inside <code> -->

<p>A React fragment looks like <code>&lt;&gt;</code> and <code>&lt;/&gt;</code>.</p>

Using <pre> blocks for larger code examples

The same escaping rules apply within <pre> elements:

<!-- ✅ Good: escaped characters inside pre -->

<pre><code>&lt;div&gt;

&lt;p&gt;Hello, world!&lt;/p&gt;

&lt;/div&gt;</code></pre>

If you frequently need to display code and find manual escaping tedious, consider using a JavaScript-based syntax highlighting library that handles escaping automatically, or use a build tool or templating engine that escapes HTML entities for you.

Unicode allows some characters to be represented in multiple ways. For example, the accented letter "é" can be stored as a single precomposed character (U+00E9) or as two separate code points: the base letter "e" (U+0065) followed by a combining acute accent (U+0301). While these look identical when rendered, they are fundamentally different at the byte level. Unicode Normalization Form C (NFC) is the canonical form that prefers the single precomposed representation whenever one exists.

The HTML specification and the W3C Character Model for the World Wide Web require that all text in HTML documents be in NFC. This matters for several reasons:

• String matching and search: Non-NFC text can cause failures when browsers or scripts try to match strings, compare attribute values, or process CSS selectors. Two visually identical strings in different normalization forms won't match with simple byte comparison.
• Accessibility: Screen readers and assistive technologies may behave inconsistently when encountering decomposed character sequences.
• Interoperability: Different browsers, search engines, and tools may handle non-NFC text differently, leading to unpredictable behavior.
• Fragment identifiers and IDs: If an id attribute contains non-NFC characters, fragment links (#id) may fail to work correctly.

This issue most commonly appears when text is copied from word processors, PDFs, or other applications that use decomposed Unicode forms (NFD), or when content is generated by software that doesn't normalize its output.

How to Fix It

1. Identify the affected text: The validator will point to the specific line containing non-NFC characters. The characters will often look normal visually, so you'll need to inspect them at the code-point level.
2. Convert to NFC: Use a text editor or command-line tool that supports Unicode normalization. Many programming languages provide built-in normalization functions.
3. Prevent future issues: Configure your text editor or build pipeline to save files in NFC. When accepting user input, normalize it server-side before storing or embedding in HTML.

In Python, you can normalize a string:

import unicodedata

normalized = unicodedata.normalize('NFC', original_string)

In JavaScript (Node.js or browser):

const normalized = originalString.normalize('NFC');

On the command line (using uconv from ICU):

uconv -x NFC input.html > output.html

Examples

Incorrect (decomposed form — NFD)

In this example, the letter "é" is represented as two code points (e + combining acute accent), which triggers the validation warning. The source may look identical to the correct version, but the underlying bytes differ:

<!-- "é" here is stored as U+0065 U+0301 (decomposed) -->

<p>Résumé available upon request.</p>

Correct (precomposed form — NFC)

Here, the same text uses the single precomposed character é (U+00E9):

<!-- "é" here is stored as U+00E9 (precomposed) -->

<p>Résumé available upon request.</p>

Incorrect in attributes

Non-NFC text in attribute values also triggers this issue:

<!-- The id contains a decomposed character -->

<h2 id="resumé">Résumé</h2>

Correct in attributes

<!-- The id uses the precomposed NFC character -->

<h2 id="resumé">Résumé</h2>

While these examples look the same in rendered text, the difference is in how the characters are encoded. To verify your text is in NFC, you can paste it into a Unicode inspector tool or use the normalization functions mentioned above. For further reading, the W3C provides an excellent guide on Normalization in HTML and CSS.

Character encoding tells the browser how to map the raw bytes of your HTML file into readable characters. When no encoding is declared, browsers must rely on heuristics or defaults to figure out which encoding to use. The validator's fallback to "windows-1252" reflects the behavior described in the HTML specification: if no encoding information is found, parsers may default to this legacy encoding. This can cause serious problems — characters like curly quotes, em dashes, accented letters, emoji, and non-Latin scripts can appear as garbled text (often called "mojibake") if the actual encoding of the file doesn't match what the browser assumes.

Why this matters

• Correctness: If your file is saved as UTF-8 (which is the default in most modern editors) but the browser interprets it as windows-1252, multi-byte characters will render incorrectly.
• Standards compliance: The WHATWG HTML Living Standard requires that a character encoding declaration be present. The encoding must also be declared within the first 1024 bytes of the document.
• Security: Ambiguous encoding can be exploited in certain cross-site scripting (XSS) attacks where an attacker takes advantage of encoding mismatches.
• Interoperability: Different browsers may choose different fallback encodings, leading to inconsistent rendering across platforms.

How to fix it

The simplest and recommended fix is to add <meta charset="utf-8"> as the first child element inside <head>, before <title> or any other elements. It must appear within the first 1024 bytes of the document so the parser encounters it early enough.

UTF-8 is the universal standard for the web. It can represent every character in Unicode, is backward-compatible with ASCII, and is the encoding recommended by the WHATWG HTML specification. Unless you have a very specific reason to use another encoding, always use UTF-8.

You should also ensure your text editor or build tool is actually saving the file in UTF-8 encoding. Declaring <meta charset="utf-8"> while the file is saved in a different encoding will still produce garbled text.

An alternative (less common) approach is to declare the encoding via an HTTP Content-Type header sent by the server, such as Content-Type: text/html; charset=utf-8. However, the <meta> tag is still recommended as a fallback for when files are viewed locally or cached without headers.

Examples

❌ Missing character encoding declaration

This document has no encoding declaration, triggering the validator warning:

<!DOCTYPE html>

<html lang="en">

<head>

<title>My Page</title>

</head>

<body>

<p>Héllo, wörld! — enjoy "quotes" and emöji 🎉</p>

</body>

</html>

✅ Fixed with <meta charset="utf-8">

Adding the <meta charset="utf-8"> tag as the first element in <head> resolves the issue:

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>My Page</title>

</head>

<body>

<p>Héllo, wörld! — enjoy "quotes" and emöji 🎉</p>

</body>

</html>

❌ Encoding declared too late

The <meta charset> must come before other content in the <head>. Placing it after a <title> that contains non-ASCII characters means the parser may have already committed to a wrong encoding:

<!DOCTYPE html>

<html lang="en">

<head>

<title>Café Menu</title>

<meta charset="utf-8">

</head>

<body>

<p>Welcome to the café.</p>

</body>

</html>

✅ Encoding declared before all other content

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>Café Menu</title>

</head>

<body>

<p>Welcome to the café.</p>

</body>

</html>

The key takeaway: always place <meta charset="utf-8"> as the very first element inside <head>. This is a small addition that prevents a whole class of character rendering and security issues.

The charset meta tag specifies an encoding name that is not the preferred form. Use utf-8 (with a hyphen) instead of utf8.

The HTML specification requires that character encoding declarations use the preferred IANA encoding name. For the Unicode UTF-8 encoding, the preferred name is utf-8, not utf8, UTF8, or other variations. While browsers may still recognize non-preferred names, the W3C validator flags them because the WHATWG HTML standard and IANA character set registry both list utf-8 as the canonical form.

This applies to the <meta charset> declaration and, less commonly, to charset parameters in Content-Type headers or <meta http-equiv> tags.

Incorrect example

<meta charset="utf8">

Correct example

<meta charset="utf-8">

When the characters right after an unescaped & spell a known entity name, the parser reads them as a character reference instead of literal text.

HTML treats & as the start of a character reference such as &, ©, or ®. Many of these references are also recognised without their trailing semicolon, so a bare & followed by a name like reg, copy, or para gets converted to ®, ©, or ¶. The validator reports this because the result is almost never what the author intended.

This usually bites in URL query strings, where parameter names happen to match entity names. In ?id=1&reg=eu, the &reg turns into ®, so the link points somewhere different from what the source shows. Escape every literal & as & to keep the text intact.

HTML examples

Invalid

<!-- &reg becomes ® and &para becomes ¶ -->

<a href="/news?id=10&reg=europe&para=3">Read the report</a>

Valid

<!-- The & characters are kept literal -->

<a href="/news?id=10&amp;reg=europe&amp;para=3">Read the report</a>

Browsers convert & back to a single & before requesting the URL, so the link works exactly as written while the markup stays valid.

Unicode allows certain characters — especially accented letters and other composed characters — to be represented in multiple ways. For example, the letter "é" can be a single precomposed character (U+00E9, NFC form) or a base letter "e" (U+0065) followed by a combining acute accent (U+0301, NFD form). While they may look identical on screen, they are different byte sequences. The HTML specification requires that all attribute values use NFC to ensure consistent behavior across browsers, search engines, and assistive technologies.

This matters for several important reasons:

• String matching and comparison: Browsers and scripts may compare attribute values byte-by-byte. An id value in NFD form won't match a CSS selector or fragment identifier targeting the NFC form, causing broken links and broken styles.
• Accessibility: Screen readers and other assistive technologies may process NFC and NFD strings differently, potentially mispronouncing text or failing to match ARIA references.
• Interoperability: Different operating systems produce different normalization forms by default (macOS file systems historically use NFD, for example). Copying text from various sources can introduce non-NFC characters without any visual indication.
• Standards compliance: The WHATWG HTML specification and W3C guidance on normalization explicitly recommend NFC for all HTML content.

The issue most commonly appears when attribute values contain accented characters (like in id, class, alt, title, or value attributes) that were copied from a source using NFD normalization, or when files are created on systems that default to NFD.

To fix the problem, you need to convert the affected attribute values to NFC. You can do this by:

1. Retyping the characters directly in your editor, which usually produces NFC by default.
2. Using a programming tool such as Python's unicodedata.normalize('NFC', text), JavaScript's text.normalize('NFC'), or similar utilities in your language of choice.
3. Using a text editor that supports normalization conversion (some editors have built-in Unicode normalization features or plugins).
4. Running a batch conversion on your HTML files before deployment as part of your build process.

Examples

Incorrect: Attribute value uses NFD (decomposed form)

In this example, the id attribute value for "résumé" uses decomposed characters (base letter + combining accent), which triggers the validation error. The decomposition is invisible in source code but present at the byte level.

<!-- The "é" here is stored as "e" + combining acute accent (NFD) -->

<div id="résumé">

<p>My résumé content</p>

</div>

Correct: Attribute value uses NFC (precomposed form)

Here, the id attribute value uses precomposed characters, which is the correct NFC form.

<!-- The "é" here is stored as a single precomposed character (NFC) -->

<div id="résumé">

<p>My résumé content</p>

</div>

While these two examples look identical in source view, they differ at the byte level. You can verify the normalization form using browser developer tools or a hex editor.

Checking and fixing with JavaScript

You can programmatically normalize attribute values:

<script>

// Check if a string is in NFC

const text = "résumé";

const nfcText = text.normalize("NFC");

console.log(text === nfcText); // false if original was NFD

</script>

Checking and fixing with Python

import unicodedata

text = "r\u0065\u0301sume\u0301" # NFD form

normalized = unicodedata.normalize('NFC', text)

print(normalized) # Outputs NFC form: "résumé"

If you encounter this validation error, inspect the flagged attribute value carefully and ensure all characters are in their precomposed NFC form. Adding a normalization step to your build pipeline is a reliable way to prevent this issue from recurring.