HTML Entity Encoder & Decoder

Introduction

HTML entity encoding sits right at the boundary between plain text and browser instructions. When you type ordinary text into a web page, most characters are displayed exactly as written. A few characters are different because the browser uses them to understand HTML itself. The less-than sign starts a tag, the ampersand starts an entity reference, and quotation marks often wrap attribute values. That is why a snippet like <strong> can act like markup in one place but should be shown literally in another. This calculator helps you deliberately choose which interpretation you want.

Use the tool in two directions. If you want to show code or user content safely inside HTML, encoding turns structural characters into entities such as <, &, and ". If you copied text from a CMS, browser inspector, template, or source file and it is full of entity references, decoding turns those references back into the characters a person expects to read. The page does the work locally in your browser, so it is quick for debugging, documentation, and everyday development tasks.

Just as importantly, the result explains what happened. After encoding, the output becomes safer to display in an HTML text context because the browser sees literal characters instead of control syntax. After decoding, the output becomes easier to read because named and numeric entities resolve back to Unicode characters. That makes this page useful both for practical escaping and for understanding why entity handling matters when you build or troubleshoot web pages.

What this tool does

This calculator converts between plain text and HTML entity references without sending your text anywhere else. It focuses on the core tasks developers and content editors run into most often: escaping text that would otherwise be treated as markup, and reversing that escaping when the goal is human-readable output instead of source-safe output.

• Encode: turns reserved characters such as <, >, &, and quotation marks into entity references so the browser shows them as text instead of treating them as markup.
• Decode: turns entity references, including named forms like & and numeric forms like © or 😀, back into the characters they represent.

That makes the tool handy when you need to display user-generated text in a page, paste examples into documentation, inspect template output, or convert copied HTML source into something readable. It is also a good reminder that escaping is context-specific. Encoding for an HTML text node is not the same as escaping a JavaScript string, a URL, a CSS value, or a SQL query.

How to use

The workflow is simple. Paste or type your text into the input box, choose whether you want to encode or decode it, and read the transformed string in the result area. If the output is what you need, use the copy button to move it into your editor, CMS, code comment, email, or documentation.

1. Paste or type text into the Input box.
2. Choose Encode to entities if the text should display literally in HTML, or choose Decode entities if the text currently contains entity references and should become readable characters again.
3. Review the Result, then copy it exactly as produced.

Tip: if you paste an already encoded string such as < and press Encode again, the ampersand is encoded too, producing <. That is called double-encoding, and it is often the clue that text was escaped more than once somewhere in a template or content pipeline.

Why HTML entities matter

HTML uses certain characters to define structure rather than content. For example, < starts a tag like <div>, & starts an entity reference such as &, and both double and single quotes often delimit attribute values. If those symbols appear in content that is meant to be shown literally, the browser may interpret them as instructions instead of text.

That difference is not just cosmetic. Sometimes it breaks layout or produces malformed HTML. In riskier situations it can contribute to cross-site scripting problems when untrusted text is inserted into a page without the correct output encoding. Entity encoding is one of the most common defenses because it converts structural characters into safe text representations that the browser displays instead of executes or parses as markup.

Named vs numeric entities

HTML supports two broad forms of entity references. Named entities are readable and memorable, while numeric entities point directly to a Unicode code point. The decoder on this page handles both styles, which is useful because real-world source text often contains a mixture of them.

• Named entities: human-readable names, for example © → ©
• Numeric entities: code points in decimal or hexadecimal, for example © or © → ©

Conceptually, decoding a numeric entity means reading the number and converting that Unicode code point back into the corresponding character. This tool handles that conversion through the browser’s own parsing behavior, which is why it can decode familiar entities quickly and consistently for common debugging use.

Formulas (reference)

A numeric entity in decimal form uses a code point $N$:

Formula: &# N;

A numeric entity in hexadecimal form uses the same code point written base-16:

Formula: &#x H;

Where $H$ is the hexadecimal representation of $N$. For example, 169 in decimal equals A9 in hexadecimal, so both © and © decode to ©.

Comparison table

Worked examples

Example 1: Encode for safe display in HTML

Input:

<script>alert("XSS")</script> & friends

Encoded output:

<script>alert("XSS")</script> & friends

Interpretation: the browser renders the literal text <script>... instead of interpreting it as markup. This is exactly what you want when a tutorial, a CMS field, a user message, or a code sample needs to be shown rather than executed.

Example 2: Decode HTML entities copied from source

Input:

Tom & Jerry © 1990

Decoded output:

Tom & Jerry © 1990

Here the goal is the opposite. The input is safe source text, but a human reader usually wants ordinary characters. Decoding makes the content readable again without changing the meaning of the text.

Example 3: Double-encoding behavior

Input:

<div>

Encode output:

<div>

This is expected. The ampersand inside < is itself a reserved character, so encoding again transforms it into &. When you see this in the wild, it often means content was escaped at two different layers, such as once in a template and again in a CMS plugin.

Reading the output correctly

The most important question after you click a button is not “Did the text change?” but “Did it change in the direction I actually need?” After encoding, you should expect to see entity references in places where raw structural characters used to be. After decoding, you should expect the opposite: entity references disappear and literal characters show up instead. The calculator never executes the text as HTML. It only transforms the string representation, which makes it safe for experimentation and troubleshooting.

It is also worth remembering that modern UTF-8 pages can display most Unicode characters directly, so you usually do not need to convert every non-ASCII symbol into an entity. The encoder here intentionally focuses on the five critical HTML characters that most often need escaping in text-node output. That narrower scope matches common developer practice and makes the result more readable than an “encode everything” approach.

• If your goal is displaying text inside HTML, the most important characters to encode are &, <, >, ", and '.
• If you are decoding and the output still contains sequences like <, the input may have been double-encoded, for example <.
• Whitespace and line breaks are preserved in the output display, so copying the result gives you the exact transformed string.

FAQ

Should I use named or numeric entities?

For the core reserved characters, named entities are conventional and easier to read in source. Numeric entities are useful when a character does not have a named entity, when you want a direct code-point reference, or when copied source already uses decimal or hexadecimal notation.

Does decoding turn < into <?

Yes. Decoding converts valid entity references into their literal characters. If you have <, decoding once yields <, and decoding twice yields <. That step-by-step behavior is often exactly what you need when diagnosing double-escaped content.

Is this enough to prevent XSS?

It helps for HTML text-node context, but safe output depends on context. JavaScript strings, CSS values, URLs, and HTML attributes each have their own escaping rules. In production code, always use the output-encoding functions recommended by your framework or templating engine for the exact context where the value is inserted.

Will this convert every Unicode character into an entity?

No. The encode mode focuses on the characters that matter most for HTML structure. Most Unicode characters can remain as normal UTF-8 text. If you need a separate “convert everything to numeric entities” workflow, that is a different task from standard HTML escaping.

Limitations & assumptions

• Encode scope: encoding targets the most important HTML-reserved characters: &, <, >, ", and '. It does not attempt to convert every non-ASCII character into a numeric entity.
• Double-encoding: if you encode text that already contains entity references, the ampersand in those references will be encoded again, for example < → <.
• Decoding validity: decoding relies on the browser’s HTML parser behavior. Invalid or incomplete entities may remain unchanged or be interpreted differently depending on their exact syntax.
• Context matters: this tool is for HTML entity encoding and decoding, not JavaScript string escaping, URL encoding, SQL escaping, or CSS escaping.
• Clipboard support: copy uses the Clipboard API when available; some browsers or privacy settings may block programmatic clipboard writes.