HTML Entities Encoder / Decoder

What HTML entities are

HTML entities are escape sequences that let you include characters in HTML which would otherwise be interpreted as markup or are difficult to type. The less-than sign < would start a tag if written literally, so HTML provides the entity < to represent it as text. The ampersand & starts an entity, so it itself needs encoding as & when you want a literal ampersand. The same is true for > (>), " ("), and ' (' — there is no standard named entity for the apostrophe in HTML4, only in HTML5 as ').

Beyond the five "unsafe" characters, entities exist for hundreds of typographic and mathematical symbols — copyright (© for ©), em-dash (— for —), non-breaking space ( ), and so on. Modern UTF-8 documents rarely need these because the characters themselves work fine; entities mostly matter when you're producing HTML that might end up in environments with limited charset support, or when you need to represent characters that would otherwise be parsed as markup.

Three encoding styles

Every entity can be written three ways. Named entities like & are the most readable but require the parser to recognize the name. Numeric entities like & use the decimal Unicode code point. Hex entities like & use the hex code point — typically what you'll see when content is auto-encoded by an editor or generated by software. All three produce identical output when rendered.

Use named when possible for HTML you write by hand — it's the most maintainable. Use numeric or hex for programmatic encoding where the entity name might not exist (most non-Latin Unicode characters don't have named entities), or when targeting older parsers that may not recognize newer named entities like ….

When you actually need encoding

• Producing HTML server-side — any user-supplied content rendered into a template MUST be HTML-encoded to prevent cross-site scripting. Modern frameworks (React, Vue, Angular, Jinja, Twig) do this by default. Plain template strings or string concatenation in legacy code do not.
• Email HTML — accented characters often break in Outlook 2007–2016. Encoding them as numeric entities (é for é) is more reliable than relying on charset declaration.
• RSS / Atom feeds — XML requires entity encoding for &, <, > at minimum.
• Inline SVG — text content inside <text> elements should be encoded if it contains XML-special characters.
• Markdown source that contains literal HTML — to display a tag rather than render it, you encode it.

Common mistakes

• Double-encoding. If a string is already encoded (<) and you encode it again, you get <. This is the most common bug in template systems — encoding happens twice because both the framework and the application code encoded. Always know whether the value coming into your template is raw or pre-encoded.
• Encoding the wrong characters. HTML-encoding ' and " matters inside attribute values, not in text content. Some libraries over-encode and produce HTML that's correct but harder to read.
• Confusing HTML encoding with URL encoding. & is for HTML; %26 is for URLs. They're not interchangeable. A URL inside an HTML attribute often needs both.
• Trusting decoded output. The decode operation is safe to display — it reverses the encoding — but if the original input contained <script>, the decoded output contains <script>. Don't decode user input and inject it into the DOM without re-encoding.

FAQ

See the FAQ section below for answers about the difference between ' and ', why   sometimes "doesn't work", whether to encode high-Unicode characters, and how to handle entity-encoded data coming from an external API.