HTML Encoder Decoder — entity converter

The HTML encoder decoder tool converts the characters that have special meaning in HTML — &, <, >, ", and ' — into their safe entity equivalents, and reverses the process to turn encoded entities back into readable text. It is one of the most frequently reached-for utilities in front-end and back-end development, because getting HTML escaping wrong is one of the most common causes of both broken page rendering and real security vulnerabilities.

Arb Digital built this converter as part of a free developer toolkit because encoding and decoding HTML correctly is something every web developer touches sooner or later, whether displaying user comments, building an email template, or debugging a scraped page full of stray entities.

What This HTML Encoder Decoder Tool Does

In encode mode, this tool scans your input text and replaces the five HTML-significant characters with their named entity equivalents: & becomes &, < becomes <, > becomes >, " becomes ", and ' becomes '. This is exactly the transformation a browser needs so that raw text — including text a user typed, which might accidentally or maliciously contain HTML syntax — displays as literal characters on the page instead of being interpreted as markup.

In decode mode, the tool does the reverse: it takes a string full of HTML entities (named entities like & or numeric entities like & and &) and converts them back into the plain characters they represent, so you can read the original text cleanly.

There's also an optional mode for encoding all non-ASCII characters as numeric entities — useful when you need output that is guaranteed to be pure ASCII, such as for older systems, certain email clients, or XML pipelines that don't reliably handle raw UTF-8 bytes.

How to Use It

1. Choose a mode. Select "Encode" to escape special characters, or "Decode" to convert entities back to readable text.
2. Paste your content. Drop in raw text, a snippet of HTML, or user-submitted content.
3. Set non-ASCII handling if needed. Turn on numeric-entity encoding for non-English characters if your target system requires pure ASCII output.
4. Review the result. The converted text appears instantly, along with a count of how many characters were escaped and which entities were used.
5. Copy and use it. Click "Copy Result" and paste the safe or decoded text into your code, CMS, or email template.

How HTML Entity Encoding Works

HTML entities exist because a handful of characters carry structural meaning in HTML markup. The browser's parser treats < and > as the start and end of a tag, & as the start of an entity reference, and quote characters as the boundaries of an attribute value. If any of these characters appear literally inside text that's meant to be displayed — rather than interpreted as markup — the parser can misread the structure of the page, breaking layout or, worse, allowing injected script to execute.

An entity reference is simply a reserved sequence that the parser recognizes and converts back into the literal character at render time: a named form like &, or a numeric form like & (decimal) or & (hexadecimal), both of which reference the character's Unicode code point. Because the parser treats these sequences specially and never confuses them with real markup, they are the correct, standards-based way to include a literal <, >, or & in visible page content. The definitive reference for named character references is maintained by the WHATWG HTML Living Standard, and MDN's HTML entity glossary is a good practical companion.

Why This Matters for Security: HTML Escaping and XSS

Beyond visual correctness, HTML escaping is a core defense against cross-site scripting (XSS), one of the most common web application vulnerabilities. XSS happens when an attacker manages to get their own HTML or JavaScript rendered as part of a trusted page — for example, by submitting a comment containing <script> tags that a vulnerable site inserts directly into the page without escaping. If the site instead HTML-encodes that user input before rendering it — turning < into < — the browser displays the literal text of the comment instead of executing it as a script.

OWASP, the leading authority on web application security, lists proper output encoding as one of the primary defenses against XSS, alongside input validation and Content Security Policy. It's important to understand, though, that HTML encoding is context-specific: text placed inside an HTML element body needs HTML entity encoding, but text placed inside a JavaScript string, a URL, or a CSS value needs different encoding rules entirely. Using this tool to HTML-encode a value before dropping it into a <script> block, for instance, will not make it safe — that requires JavaScript string escaping instead.

Named vs. Numeric Entities

HTML supports two entity styles. Named entities like &, <, ©, and   are human-readable shorthands defined in the HTML specification, but only a fixed set of names is recognized — several hundred common symbols. Numeric entities like © (decimal) or © (hexadecimal) reference any Unicode code point directly and work universally, even for characters that have no named shorthand, such as emoji or rare symbols. This tool's "encode all non-ASCII as numeric entities" option uses this universal numeric form, which is why it can safely handle any character your text contains, not just the handful with dedicated names.

Common Mistakes to Avoid

• Encoding in the wrong context. HTML entity encoding protects HTML element content and attributes, not JavaScript strings, URLs, or CSS — each context needs its own escaping rules.
• Double-encoding. Running already-encoded text through the encoder again turns & into &, corrupting the display. Always decode first if you're unsure of the current state.
• Relying on client-side encoding alone for security. XSS defenses must happen on the server (or in the rendering layer) for any content that reaches other users — client-side encoding in a browser tool like this is for content preparation, not a substitute for a real security review.
• Forgetting the apostrophe. Some hand-written escaping functions forget to encode ', leaving single-quoted HTML attributes vulnerable.
• Assuming entities work everywhere. Named entities are an HTML-specific feature; plain-text emails, JSON payloads, and most non-HTML formats do not interpret them and will display them literally.

Related Free Tools From Arb Digital

Pair this converter with the Base64 Encode Decode tool for binary-safe encoding, the Text to Binary Converter and Binary to Text Converter for byte-level work, and browse our full free online tools hub for more developer utilities.

The Five Characters You Must Escape

HTML gives special meaning to a handful of characters, and encoding is simply the act of neutralising that meaning so text displays as text. The critical five are & (must become & first, because every other entity starts with it), < (<) and > (>) which would otherwise open and close tags, and the quotes " (") and ' (') which can break out of attribute values. Encode those and a string like <script> shows up on the page as visible text rather than executing — which is precisely why encoding sits at the heart of preventing cross-site scripting (XSS).

The order matters: always escape the ampersand first. If you replace < with < and only then escape ampersands, you would double-encode and turn your < into <, which renders as the literal text "&lt;" instead of a "<" symbol. A correct encoder — like the one above — handles this sequencing for you, but knowing the rule explains the classic bug where user input shows up peppered with stray & fragments after passing through two layers of naive escaping.

Context Is Everything: Element Text vs Attributes

A single escaping strategy is not enough, because the rules change with where the data lands. Text that sits between tags — inside a paragraph or a heading — mainly needs &, < and > handled. Text placed inside an attribute value additionally needs the relevant quote character escaped, or an attacker can close the attribute early and inject their own; that is why robust encoders escape both quote types. Data destined for a URL, a JavaScript string, or a CSS value needs entirely different encoding again — URL-encoding, JS string escaping, and so on.

The professional habit is "encode at the point of output, for the context you are outputting into." The same username might be HTML-entity-encoded when shown in a comment, URL-encoded when placed in a link, and JavaScript-escaped when injected into a script variable — three different transformations of one value. This tool covers the HTML side, which is by far the most common, but the underlying lesson carries everywhere: never trust that input is safe, and always match the escaping to the destination. That discipline is the difference between a site that resists injection and one that ships an XSS hole on its first user-generated field.

Frequently Asked Questions

This tool runs entirely in your browser using built-in JavaScript. Nothing you type or paste is uploaded, stored, or sent to any server.