HTML Entity Encoder & Decoder for Safe Text Display

Introduction to HTML entity encoding and decoding

HTML entity encoding sits at the seam between readable text and HTML syntax. In a browser, most characters are just characters, but a small set of symbols tell the parser how a page is built. The less-than sign begins a tag, the ampersand introduces an entity reference, and quotation marks can frame attribute values. That is why the string <strong> can be harmless text in one place and active markup in another. This calculator is for deciding which of those two roles your text should play.

Use the tool both ways. When you need to show code samples, pasted comments, user posts, or template fragments literally inside HTML, encoding converts structural characters into sequences such as <, &, and ". When you are looking at copied source that already contains entities, decoding turns those references back into the characters people expect to read. Everything happens in your browser, so it is a quick way to clean up snippets during debugging, documentation, and everyday content work.

The output is also useful as a teaching aid. After encoding, the browser treats the result as plain text in an HTML text context instead of as markup. After decoding, named and numeric references collapse back into Unicode characters, which makes copied code easier to inspect. That is why this page works well for both practical escaping and for learning where HTML ends and literal content begins.

What this HTML entity tool does

This HTML entity encoder/decoder converts between normal text and entity references without uploading your content. It is aimed at the two chores people run into most often: making HTML-safe text from characters that would otherwise be parsed, and reversing that escaping when the goal is readable copy instead of source-safe copy.

• Encode: turns characters like <, >, &, and quotation marks into entity references so a browser shows them as text.
• Decode: turns named entities like & and numeric entities like © or 😀 back into the characters they represent.

That makes the page handy when you are pasting examples into documentation, checking CMS output, inspecting generated templates, or converting HTML source into something a person can read quickly. It also highlights an important rule: escaping depends on context. HTML text-node encoding is not the same as escaping a JavaScript string, URL, CSS value, or database query.

How to use the HTML entity encoder & decoder

The workflow on this page is straightforward: paste text into the input box, choose whether it should become entity-safe HTML or readable characters, and inspect the transformed result. If the output fits your destination, copy it into your editor, CMS, code sample, or message exactly as shown.

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 in a template or content pipeline.

Why HTML entities matter in HTML output

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 HTML entities

HTML entity decoding works with two broad styles of reference. Named entities are the familiar short forms that are easy to recognize in source, while numeric entities point directly to a Unicode code point. Because real copied text often mixes the two, the decoder on this page is useful when you are cleaning up snippets from editors, inspectors, or content systems.

• 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.

HTML entity formulas (reference)

A decimal numeric HTML entity uses a code point :

Formula: &# N;

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

Formula: &#x H;

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

HTML entity types comparison table

This table compares the entity forms you are most likely to see when encoding or decoding HTML text. The browser understands both named and numeric references, but they each have different strengths depending on whether readability or direct code-point control matters more.

Worked examples: encoding and decoding HTML entities

Example 1: encode angle brackets and quotes for safe HTML display

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: spot double-encoding in entity text

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 HTML entity 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 about HTML entity encoding and decoding

Should I use named or numeric HTML entities?

For the core reserved characters, named entities are usually easier to read in source. Numeric entities are useful when a character does not have a named form, 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 literal characters. If you have <, decoding once yields <, and decoding twice yields <. That step-by-step behavior is often exactly what you need when tracing 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.

HTML entity encoder 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.