Encode HTML special characters (&, <, >, ", ') into named or numeric entities, or decode HTML entities back to plain text — live, as you type.
HTML uses a handful of characters as syntax rather than content: angle brackets (< and >) mark the start and end of tags, the ampersand (&) marks the start of an entity reference, and quote characters (" and ') delimit attribute values. Because these characters carry special meaning to an HTML parser, any of them appearing literally inside text you actually want displayed can be misread as markup instead — a stray < can silently start a tag that was never meant to exist, breaking the rest of the page's layout in ways that are often confusing to debug. HTML entity encoding solves this by replacing each special character with a reference the parser recognizes as 'this is literal text, not markup' — < instead of <, & instead of &, and so on — while still rendering as the original character on the page.
Both formats are fully valid, standard HTML, rendered identically by every browser — the choice is mostly about readability and context. Named entities (&, <, ") are self-documenting; a developer reading the HTML source can immediately tell what character is meant without decoding a number. Numeric entities (&, <, ") rely only on the universal Unicode code-point-to-character mapping rather than a memorized or looked-up name table, which makes them a common choice in automated pipelines, certain XML-adjacent formats, or contexts where you want output that's unambiguous regardless of which named-entity set a downstream parser supports. Neither is 'more correct' — pick named entities for hand-written or reviewed markup, and numeric entities when you want maximally portable, unambiguous output.
Beyond just avoiding broken rendering, correct HTML entity encoding is one of the foundational defenses against cross-site scripting (XSS) — a vulnerability class where an attacker gets their own HTML or JavaScript to run inside a page by injecting it through a form field, URL parameter, or any other place user-controlled text ends up rendered on a page. If user input containing `<script>...</script>` or `" onmouseover="...` is inserted into HTML without encoding the special characters first, the browser can interpret it as real, executable markup instead of inert text. Encoding & first (so that any entity-like sequences in the original input don't get double-interpreted), then <, >, ", and ' neutralizes this — the browser displays the literal characters instead of acting on them. This is exactly the escaping logic modern templating engines (and this tool) apply automatically.
This tool only touches the five HTML-syntactically-significant characters — it leaves accented letters, symbols, emoji, and other Unicode text completely untouched on the Encode side. That's intentional: on a modern, UTF-8-declared web page (the near-universal default today), characters like é, ñ, €, or 🎉 render correctly without any entity encoding at all, so encoding them would only add noise to your HTML source for no real benefit. Older tools that encode 'every non-ASCII character' as entities are solving a problem — non-UTF-8 page encodings — that's largely obsolete for modern web development. If your project has a genuine, specific need to escape a much broader character set, that calls for a different, purpose-built tool.
Decoding runs in three passes. First, hexadecimal numeric entities (< and similar) are converted using their hex code point. Second, decimal numeric entities (< and similar) are converted using their decimal code point — both of these passes work for any valid Unicode code point, since they're pure arithmetic conversions rather than table lookups. Third, named entities (&, é, —, and so on) are matched against a broad table covering the five basic HTML-special characters plus the everyday punctuation, currency, typographic, and accented-letter entities you're most likely to actually encounter in real-world HTML. An entity name the table doesn't recognize is left untouched in the output rather than silently dropped or guessed at, so you can always spot anything the decoder couldn't resolve.
HTML encoding and decoding comes up constantly in everyday development and content work: preparing a code snippet to display literally inside a `<pre>` or `<code>` block on a blog or documentation site (where the snippet itself might contain < and > that would otherwise be parsed as real tags), cleaning up text copied from a CMS or RSS feed that arrives full of entity-encoded characters, debugging why a piece of user-submitted text isn't rendering the way you expect, or manually testing how a backend handles specially-encoded input. Because this tool runs entirely client-side with live conversion as you type, it's a fast way to check either direction without spinning up a script or opening dev tools.
HTML Encoder/Decoder pairs naturally with these other developer text-conversion tools.