Does the HTML Entity Encoder / Decoder support named references like ©?

Yes. The tool uses the browser’s current WHATWG named-character-reference table, so it supports all current named references, including legacy aliases and references that map to multiple code points.

Can I use this tool to sanitize dangerous HTML?

No. The encoder escapes common HTML syntax characters in a string, but it does not sanitize a document or make arbitrary insertion contexts safe. Always use a dedicated sanitizer or framework auto-escaping for untrusted HTML.

Why are non-ASCII characters optional in encoding mode?

Modern UTF-8 HTML can normally contain non-ASCII characters directly, so numeric references are unnecessary for readability. Non-ASCII mode is useful only for specific workflows, such as legacy systems or transport layers that require numeric representations.

What happens if I decode a reference that looks like markup?

Decoding a reference like <script> will produce the literal characters . The tool does not execute this string, but copying it into an unsafe HTML sink (e.g., innerHTML) could create a vulnerability. Always treat decoded output as untrusted text.

Does the tool work with XML references?

XML has a much smaller predefined entity set and different parsing rules than HTML. The tool is designed for HTML character references and may not support all XML entities. For XML workflows, use a dedicated XML encoder or consult the XML specification.

Is there a limit to the input size?

Yes. The tool limits input to 500,000 JavaScript characters to ensure fast, predictable processing. For larger inputs, split the text into smaller chunks and process them separately.

Escape HTML Characters Without an API: Browser-Based Encoding

An HTML escape API alternative that runs entirely in the browser lets you convert reserved HTML characters to safe references—or decode them back—without uploading text or waiting for network responses. HTML Entity Encoder / Decoder handles both tasks instantly: encode ampersand, less-than, greater-than, double quote, and apostrophe into their standard HTML-safe forms, and optionally convert every non-ASCII code point above 126 to uppercase hexadecimal numeric references. Decode mode reverses the process, using the browser’s current WHATWG named-character-reference table to resolve named entities like ©, decimal references like ©, and hexadecimal references like © into their Unicode characters. Because the tool operates locally, there are no rate limits, no external dependencies, and no privacy concerns—input never leaves the browser.

This approach is ideal for developers who need to prepare user-generated text for safe HTML insertion, debug malformed markup, or migrate legacy content that relies on numeric references. Unlike remote APIs, the browser-based encoder never times out, never charges per request, and never exposes sensitive data to third-party servers. The tool also avoids the common pitfall of double-encoding: it encodes ampersands first, so newly created references are never re-encoded in the same operation. For workflows that require numeric references for non-ASCII characters—such as legacy systems, transport layers, or teaching examples—non-ASCII mode converts every code point above 126 to an uppercase hexadecimal reference, while keeping ASCII letters, numbers, spaces, tabs, and line breaks readable.

When to Use a Browser-Based HTML Escape Tool

Use HTML Entity Encoder / Decoder when you need to escape or unescape HTML characters without relying on a remote API. Common scenarios include:

Preparing user-generated content for safe insertion into HTML templates or CMS fields.
Debugging or cleaning malformed markup that contains mixed named and numeric references.
Migrating legacy content that uses numeric references for non-ASCII characters.
Teaching or demonstrating how HTML character references work without exposing students to server-side dependencies.
Local development or testing where network access is restricted or unreliable.

The tool is not a substitute for framework auto-escaping, a trusted templating engine, or a dedicated sanitizer. It does not sanitize HTML documents or make arbitrary insertion contexts safe. Instead, it provides a fast, private way to convert between literal characters and HTML references, so you can integrate the output into a context-aware workflow.

How HTML Character Escaping Works

HTML uses specific characters—ampersand (&), less-than (<), greater-than (>), double quote ("), and apostrophe (')—to define markup syntax. When you need to include these characters as literal text in an HTML document, you must escape them to prevent the browser from interpreting them as markup. Escaping converts these reserved characters into named or numeric references, which the browser renders as the original characters. For example, the less-than symbol (<) is rendered as < in the browser, but the underlying HTML source contains <.

The WHATWG HTML Living Standard defines a comprehensive table of named character references, including legacy aliases and references that map to multiple code points. For instance, the named reference © resolves to the copyright symbol (©), while ∉ resolves to the "not an element of" symbol (∉). Numeric references, such as © (decimal) or © (hexadecimal), provide a way to represent any Unicode character, including those without a named reference. The browser’s HTML parser handles both named and numeric references, converting them into their corresponding Unicode characters during rendering.

When escaping text for HTML, it’s important to choose the right mode for your use case. Basic encoding replaces only the five reserved syntax characters, leaving non-ASCII characters like © or 😀 as literal Unicode. This approach is recommended for modern UTF-8 HTML, where unnecessary references can reduce readability. Non-ASCII mode, on the other hand, converts every code point above ASCII 126 to an uppercase hexadecimal numeric reference, which is useful for legacy systems or workflows that require numeric representations. The encoder iterates Unicode code points rather than UTF-16 code units, ensuring that emoji and supplementary characters are encoded as single references rather than invalid surrogate pairs.

Encode or Decode HTML Characters Step by Step

Open the HTML Entity Encoder / Decoder tool in your browser.
Choose whether you want to Encode characters or Decode references.
If encoding, select an encoding mode:
- Basic: Escapes only ampersand, less-than, greater-than, double quote, and apostrophe.
- Non-ASCII: Escapes the same syntax characters and additionally converts every code point above ASCII 126 to an uppercase hexadecimal numeric reference.
Paste your source text into the input area. The tool accepts up to 500,000 JavaScript characters.
Select the Convert button to process the text.
Inspect the output for reserved characters, especially ampersands and angle brackets. The tool encodes ampersands first to prevent double-encoding of newly created references.
Copy the output only after confirming it matches your intended use case. Remember that decoded text may contain markup-looking characters, so treat it as untrusted data and use context-aware escaping at the final output boundary.

Context-Sensitive Escaping: What the Tool Does Not Do

HTML Entity Encoder / Decoder is designed for general HTML syntax escaping and reference decoding, but it is not a universal solution for all text-safety needs. Character references are context-sensitive, meaning the same escaped string may not be safe for all HTML contexts, let alone other languages like JavaScript, CSS, SQL, or HTTP headers. For example:

Encoding text for an HTML text node is not the same as safely constructing a URL, a JavaScript string, or a CSS value. Each context requires its own escaping rules.
The tool does not sanitize HTML documents or prevent injection attacks. Decoding references can reveal markup-looking text, such as <script> becoming the literal characters <script>. While the tool does not execute this string, copying it into an unsafe innerHTML sink could create a vulnerability.
XML has a much smaller predefined entity set and different parsing rules than HTML. If your downstream system uses XML, remember that XML parsers may not recognize all HTML named references.

For reliable use, always choose the operation first, paste a small representative sample, run the conversion, and inspect the output before processing a larger block. Copy the result only after confirming the receiving context. If you need to escape text for a specific framework or templating engine, consult its documentation for context-aware escaping functions, such as esc_html() in WordPress or auto-escaping in React.

Encoding Modes Compared

Mode	Characters Escaped	Non-ASCII Handling	Use Case
Basic	Ampersand (&), less-than (<), greater-than (>), double quote ("), apostrophe (')	Left as literal Unicode	Modern UTF-8 HTML where readability is a priority
Non-ASCII	Same as Basic	Converted to uppercase hexadecimal numeric references (e.g., © becomes ©)	Legacy systems, transport layers, or teaching examples that require numeric references

Decoding HTML References: What to Expect

Decode mode resolves all current WHATWG named, decimal, and hexadecimal references into their Unicode characters. The tool uses a detached textarea element to ask the browser’s HTML parser to apply the full named-character-reference table, including legacy aliases and references that map to multiple code points. For example:

The named reference ∉ decodes to the "not an element of" symbol (∉), which is a single Unicode character.
The named reference ¬ decodes to the "not sign" (¬), which is distinct from ∉.

Because the browser’s parser handles the decoding, the tool supports the complete current table without requiring a remote fetch or manual updates. However, decoded output may contain markup-looking characters, so it should always be treated as untrusted text. Never place decoded output directly into an unsafe HTML sink, such as innerHTML or document.write(), without additional context-aware escaping.

Practical Example: Escaping User-Generated Content

Suppose you are building a blog comment system and need to safely display user-generated text in an HTML template. The user submits the following comment:

I love this post! <script>alert('XSS');</script> 😀

To safely render this comment in HTML, you need to escape the reserved syntax characters while preserving the emoji. Using the HTML Entity Encoder / Decoder in Basic mode, the input is converted to: