Free HTML Entity Encoder Online

An html entity encoder replaces characters that have special meaning in HTML — mainly <, >, and & — with their entity equivalents, so the text displays as literal characters instead of being parsed as markup. Decoding does the reverse: it turns &amp; back into & and &lt; back into <. This comes up constantly for anyone writing documentation with code snippets, displaying user-submitted text safely, or working with content that's been scraped or exported and needs its entities resolved back to readable characters. This guide covers exactly which characters this tool touches, what "named," "numeric," and "hex" entity formats actually mean, and where entity encoding fits relative to full HTML sanitization.

How the HTML Entity Encoder Works

The interface is a genuine side-by-side dual pane, not a single box that swaps contents — input on the left, output on the right, connected by a swap button in the middle:

• Type or paste text into the left pane. Conversion happens live as you type, with no separate convert step.
• Choose a direction: Encode turns literal characters into entities; Decode turns entities back into literal characters. The swap button flips both the direction and the pane contents in one click, which is handy when you're iterating on a snippet.
• Pick an output format for encoding: Named produces readable entities like &amp; and &copy; where a name exists; Numeric produces decimal codes like &#38;; Hex produces hexadecimal codes like &#x26;. All three are valid HTML and render identically in a browser — the difference is purely how the entity is written in the source.
• Toggle "Encode all characters" to switch from selective encoding (only the handful of HTML-special characters) to encoding every character in the input, useful when you specifically need a fully entity-escaped string rather than one where only the structurally dangerous characters are touched.
• Copy the result with the button above the output pane.

It's worth being precise about scope here: by default, only five characters get encoded — &, <, >, ", and ' — because those are the ones that actually change how HTML is parsed. A character like an em dash or a heart symbol that isn't one of those five, and isn't in the tool's small named-entity list, passes through completely unchanged unless you turn on "Encode all characters." That's expected behavior, not a gap — most of the time you want exactly that selective behavior, since blanket-encoding every character in a paragraph of prose produces a much longer string for no real benefit. For automating entity conversion outside the browser — in a build step or content pipeline — the same logic is available as an API endpoint at /docs.

When to Encode or Decode HTML Entities

Entity encoding solves a narrow but recurring problem: making sure text that contains HTML-meaningful characters displays as text instead of being interpreted as markup. Common cases:

• Showing code snippets in documentation or a blog post. A snippet containing <div> or a comparison operator like && will be silently swallowed by the browser as markup unless the angle brackets and ampersands are entity-encoded first, which is why documentation sites universally run source code through entity encoding before embedding it in a page.
• Writing typographic symbols directly into HTML source. Characters like copyright, trademark, an em dash, or a non-breaking space are sometimes typed as entities directly in hand-written HTML rather than as raw Unicode characters, particularly in older codebases or templates where character encoding wasn't guaranteed to be UTF-8 throughout the pipeline.
• Escaping user-submitted text before display. If a comment, review, or form submission is inserted into a page's HTML, any angle brackets or ampersands in it need to become entities first, or a user typing something that looks like a tag could break the page's layout — or worse, inject an actual script tag.
• Preparing text for RSS, Atom, or email HTML templates. These formats are strict about well-formed markup, and un-encoded ampersands or angle brackets in dynamically inserted text are one of the most common reasons a feed or templated email fails to validate or render correctly.
• Decoding scraped or exported HTML content. Content pulled from an API, exported from a CMS, or scraped from a page often arrives with entities still in place. Decoding it back to plain text is necessary before doing anything else with it — searching it, displaying it outside an HTML context, or feeding it into something that expects plain text.

One thing this tool is deliberately not: a full HTML sanitizer. Encoding the five special characters neutralizes the most direct injection vector, but if you're accepting rich, structured HTML from untrusted users and need to allow some tags while stripping others, that's a different job — handled by a dedicated sanitization library, not a character-substitution tool like this one.

Inside HTML Entities: Named, Decimal, and Hex

HTML entities exist because the HTML specification reserves a handful of characters for markup syntax. < opens a tag, & begins an entity reference, and quote characters delimit attribute values — so text that needs to contain those characters literally has to use an escaped form instead.

The HTML specification actually defines well over a thousand named entities covering everything from mathematical symbols to accented letters in multiple alphabets. This tool covers a focused, commonly used subset — the five structurally required characters plus roughly twenty familiar symbols: copyright, registered trademark, trademark, several currency symbols, degree and multiplication signs, em and en dashes, ellipsis, non-breaking space, and the four arrow directions. That's a deliberate, honest scope rather than an attempt to replicate the full named-entity table — anything outside that list still encodes correctly, just as a numeric entity rather than a named one.

All three formats this tool produces are functionally identical once rendered:

Format	Example (ampersand)	Readability	Universality
Named	&	High — self-explanatory in source	Limited to entities with an assigned name
Numeric (decimal)	&	Low — requires knowing the code point	Works for every Unicode character
Hex	&	Low — requires knowing the hex code point	Works for every Unicode character, common in generated markup

Named entities read better in source code, which is why documentation and hand-written HTML favor them for common characters. Numeric and hex entities have the advantage of covering absolutely any character, including ones with no assigned name, which is why they show up more often in machine-generated markup or when working with less common symbols the named list doesn't cover.

HTML Entity Encoder vs Other Approaches

Entity encoding by hand isn't the only way this problem gets solved in practice:

• Template engine auto-escaping. Frameworks like Django, Jinja2, and React's JSX escape interpolated values automatically by default, which is the right long-term answer for an application — but doesn't help with a one-off snippet for a blog post or a piece of text you're preparing outside that framework.
• Language-level escaping functions. PHP's htmlspecialchars(), Python's html.escape(), and equivalents elsewhere do the same core job programmatically, and are the right choice when escaping is one step in a larger script rather than a manual task.
• Manual find-and-replace. Technically possible for the five special characters, but error-prone once you also need numeric or hex output, or need to handle a symbol outside the basic set — easy to miss a character or introduce a typo in the entity code.
• An online HTML entity encoder. No script to write, no framework dependency — paste text in, pick a format, get output immediately, with a decode path for the reverse direction built into the same interface. It's suited to one-off text preparation, not high-volume automated escaping across an entire application, which belongs in your templating layer or the API.

How Your Data Is Processed

All encoding and decoding happens directly in your browser through JavaScript running on the page — nothing you type or paste is sent anywhere or stored. That matters for anyone pasting in content that isn't meant to be public yet, like draft documentation, unpublished text, or user data being prepared for review before it's ever inserted into a live page.

HTML Entity Questions Worth Answering

Why didn't a symbol like a heart or an emoji get encoded?

By default, only the five characters with actual HTML syntax meaning — &, <, >, ", and ' — are encoded, along with a small set of common named symbols. A heart symbol or emoji isn't structurally dangerous in HTML and isn't in that named list, so it passes through unchanged unless "Encode all characters" is switched on, which forces every character in the input to be converted to a numeric entity.

Is entity-encoding text enough to prevent an XSS vulnerability?

It's the core mechanism behind preventing the most common form of it — encoding angle brackets prevents a submitted string from being parsed as a new tag. But a complete defense against cross-site scripting also depends on context (encoding differs for HTML body text versus an HTML attribute versus a URL) and, for rich content that needs to allow some HTML, a proper sanitization library rather than blanket character escaping.

What's the difference between decimal and hex numeric entities?

Both reference the same Unicode code point for a character, just written in different number bases — &#169; and &#xA9; both render as the copyright symbol. Neither is more "correct" than the other; the choice is usually just a matter of which convention a codebase or generator already uses.

Will decoding entities in untrusted text make it safe to insert as HTML?

No — decoding does the opposite of what you'd want for safety. It turns entities back into literal characters, including < and >, which means decoded text should never be inserted directly into a page as HTML. Decoding is for turning entity-laden text back into plain, readable text, not for preparing content to be rendered as markup.

Why does the same ampersand appear as &amp; in some HTML and &#38; in other HTML?

Both are valid and render identically. The difference usually comes down to which tool or library generated the markup — some prefer named entities for readability, others default to numeric entities because they require no lookup table, just the character's code point.

Related Tools

If the text you're preparing needs to go into a URL rather than HTML markup, URL Encode/Decode handles that separate encoding scheme, and the two are easy to reach for interchangeably by mistake. Once your HTML entities are resolved and you have clean markup, HTML Formatter can re-indent and structure it for readability. If you're converting between HTML and a lighter markup format, Markdown to HTML covers that direction of the workflow. Text that needs Base64 rather than entity encoding — for embedding in a data URI, for instance — belongs in Base64 Encode/Decode instead. And if you need entity conversion wired into a content pipeline instead of pasted by hand, the same functionality is available as a metered API endpoint — see /docs for details.