HTML Encoder Online

An HTML document is text that doubles as code: angle brackets open elements, ampersands open references, quotes delimit attributes. The moment any of those characters should be displayed rather than interpreted, the document needs a way to say "this is data, not markup" — and that way is the character reference, written either by name (&lt;, &amp;, &quot;) or by codepoint (&#60;, &#38;). When the browser meets &lt; inside element text it renders a literal < instead of starting a tag. That single mechanism is what lets every tutorial on the web show source code, what lets a comment form accept the text <script> without executing it, and what lets HTML carry math like a < b intact.

Escaping matters in two very different jobs. The defensive job is security: any untrusted string — form input, URL parameters, database rows — must be escaped before it is placed into HTML output, or a user can inject markup that the browser will happily execute. The presentational job is documentation: showing markup as text inside a page, code sample or tutorial. This tool serves both, but it is worth being precise about the boundary: encoding characters is not sanitization. It renders potentially dangerous input harmless in one context (element text), while a real sanitizer parses the document and removes dangerous constructs entirely.

Named references are words the HTML Standard defines, like &copy; for ©, &mdash; for — and &nbsp; for a non-breaking space. They are readable and self-documenting, which is why hand-written HTML and most CMS content favors them. Numeric references write the Unicode codepoint directly: &#169; or &#xA9; is the same character as &copy;, and any codepoint can be written this way even when no name exists — the medal emoji 🎖 has no short memorable name, but &#127894; renders it everywhere. Numeric form is also the only option when you need guaranteed ASCII output, because every reference it produces is itself pure ASCII.

The practical split: use named for the handful you can type from memory (&amp; &lt; &gt; &quot; &nbsp; &copy;) and numeric for everything a pipeline might mangle. One quirk worth knowing: in HTML, the apostrophe has no memorable legacy name — &apos; was only added in XML and later HTML5 — which is why this encoder, like most server-side frameworks, writes &#39;. It is the maximally compatible form, understood by every HTML and XML parser back to the 1990s.

Escape at the last moment, in the output context, is the rule professionals follow. A string that will become HTML gets encoded as it is written into the template (modern frameworks do this by default — React's JSX, Angular interpolation and Vue's mustaches all escape automatically); a string that will become a URL gets percent-encoded; a string that will become SQL gets parameterized. The bug pattern is escaping at the wrong layer: storing pre-escaped text in the database leads to &amp;amp; rendering to users, and double-escaping is the most common entity bug in the wild. If your decoded output still contains visible entities like &lt;, the text was encoded twice — run Decode once more to check.

There is also a context where you should not encode at all: inside <script> and <style> blocks, entity references are not parsed, so &lt; stays literally four characters and breaks your JavaScript. JSON payloads embedded in HTML are protected instead by escaping the sequence that could close the tag — replacing < with \u003C inside the JSON — which is exactly what JSON.stringify produces for such contexts. When in doubt about what a payload will do once it lands in a page, paste it into the HTML tester and watch the console; the renderer will tell you faster than any rule of thumb.