HTML Encoder

Why raw text breaks web pages

HTML is a markup language, which means certain characters are instructions, not content. A < tells the browser "a tag starts here"; an & says "an entity starts here". When text that was never meant to be markup contains those characters — a blog comment reading "I love <div> elements", a forum post comparing a > b — the browser obediently parses them as structure. The comment vanishes into a phantom element, the rest of the page nests inside it, and the layout collapses in ways that are miserable to debug.

Escaping converts those instruction characters into inert display characters. The text <div> becomes &lt;div&gt;, which the browser renders as the literal four characters "<div>" on screen. Your content says exactly what you typed, and the page structure stays untouched.

Attribute values deserve special mention because they are the easiest place to get bitten. A quote inside an attribute — title="He said "hello"" — terminates the attribute early, and whatever follows can become a new, attacker-controlled attribute. Encoding " as &quot; and ' as &#39; closes that hole, which is why this tool's Basic mode always escapes all five core characters rather than the minimal three some tutorials suggest.

How encoding neutralizes XSS attacks

Cross-site scripting happens when attacker-supplied text reaches a page as executable markup: a comment containing <script>stealCookies()</script> that the site renders raw. If every dynamic value is escaped at output time, that input becomes &lt;script&gt; — visible, harmless text. The payload never executes because the browser never sees a real tag.

One honest caveat: encoding is one layer, not a security strategy by itself. Different contexts (HTML body, attributes, JavaScript strings, URLs) need different escaping rules, and mature apps pair output encoding with input validation, Content Security Policy headers and sanitization libraries. But correct escaping is always the foundation — and testing what your escaped output actually looks like is exactly what this tool is for.

Encoding for display vs sanitizing for security

These two operations are constantly confused, and the difference matters. Encoding for display is what this tool does: transform text so the browser shows it literally. It is deterministic, reversible and context-specific — you encode because you want the characters visible on the page, whether you are publishing a code tutorial, documenting an API payload or quoting HTML in an email.

Sanitizing for security is a different discipline: parsing untrusted HTML and removing anything dangerous — scripts, event handlers, rogue iframes — while keeping safe formatting intact. Sanitization requires a real parser and an allowlist, which is why libraries like DOMPurify exist. Encoding untrusted input at output time is your baseline defense, but if you intentionally accept HTML from users, you need a sanitizer too.

The practical workflow: store content raw in your database, escape it every time you render it into a page, and encode by hand with a tool like this one whenever you are preparing examples, templates or documentation. Encoding should happen at the last possible moment — at output — because double-encoding stored content is how you end up with &amp;lt; showing on the page.

Named vs numeric entities, and when extended mode helps

Named entities like &amp; and &copy; are self-documenting — anyone reading your source knows what character was intended. Numeric entities (&#38; decimal, &#x26; hexadecimal) work for every Unicode code point, including the thousands of characters that have no named form. All three styles are equally valid HTML; pick named for readability, numeric for completeness, hex to match byte-oriented documentation.

Extended mode converts every non-ASCII character — é, ©, €, emoji — into entities. That is invaluable when content must survive legacy systems: databases stuck in Latin-1, email templates that mangle UTF-8, or build pipelines that strip high bytes. café becomes caf&eacute; (or caf&#233;), which renders identically in any encoding. Modern UTF-8 pages rarely need it, but when you need it, nothing else will do.