Tools Guides
developer Free No signup

HTML Entity Encoder / Decoder

Encode special characters to HTML entities and decode entities back to plain text — supports named and numeric entities.

Loading tool…

About this tool

Convert text with special characters (&, <, >, ", ') to safe HTML entities for embedding in web pages, and decode HTML entity strings back to readable text. Supports named entities (&amp;), decimal (&#38;), and hexadecimal (&#x26;) encoding.

How to use

  1. 1 Choose Encode or Decode mode.
  2. 2 Paste your text into the input field.
  3. 3 Select encoding style: named entities, decimal, or hexadecimal.
  4. 4 Click Copy to copy the result.

What HTML entities are and why they exist

HTML reserves a few characters to mean something structural. The browser reads < as the start of a tag, > as its end, and & as the beginning of an entity reference. If those characters appear literally inside your content, the browser tries to interpret them as markup, and your page breaks — or worse, an attacker can inject their own tags. An HTML entity is the safe stand-in: a coded sequence that the browser renders as the original character without treating it as markup. This tool converts text to entities (encoding) and turns entities back into readable characters (decoding).

The three ways to write the same character

Every character has more than one valid entity form, and this encoder supports all three:

FormExample for & (ampersand)How it is built
Named&amp;A human-readable name, available for common characters
Decimal numeric&#38;The character's Unicode code point in base 10
Hexadecimal numeric&#x26;The same code point in base 16

All three render identically in any browser — 38 in decimal is 26 in hexadecimal, and both point to the same Unicode character. Named entities like &copy; or &mdash; are easiest to read, but they only exist for a defined set of characters. Numeric forms work for any character, which is why they are the fallback when no name exists. The hex form is common in CSS and Unicode tables; the decimal form reads more naturally to most people.

How encoding decides what to touch

By default the encoder leaves ordinary text alone and only converts the characters that actually need it — the markup-significant ones (&, <, >, ", ') plus a set of common symbols like ©, , , , and arrows. Plain ASCII letters and digits pass through untouched, keeping the output readable. If you tick Encode all chars, every single character is converted to an entity, including normal letters. That maximal form is occasionally used to obscure an email address from naive scrapers or to guarantee a character set survives a fussy pipeline, but for everyday use the default selective encoding is what you want.

A worked example

Suppose a user types a comment: Tom & Jerry <3 "pizza" and you need to display it safely on a page. Paste it into the input with Named encoding selected and you get:

Tom &amp; Jerry &lt;3 &quot;pizza&quot;

The ampersand became &amp;, the less-than became &lt;, and the double quotes became &quot;. Dropped into your HTML, the browser renders the original text exactly as the user typed it — and crucially, the <3 can no longer be mistaken for the start of a tag. Switch the radio to Decimal and the same input yields &#38;, &#60;, and &#34; instead; the rendered result is identical.

Decoding: turning entities back into text

Click Decode and the tool runs the process in reverse. It recognises named entities, decimal references like &#169;, and hexadecimal references like &#x2122;, converting each back to its character. This is useful when you copy a snippet out of a web page's source, an API response, or an email's raw HTML and want the human-readable version. The Swap button moves the output back into the input, so you can encode something, swap, and decode it to confirm you get the original back — a quick way to sanity-check a round trip.

Why this prevents real security bugs

The most common web vulnerability, cross-site scripting (XSS), happens when user-supplied content is inserted into a page without encoding. If a visitor's "name" is <script>steal()</script> and you print it raw, the browser runs that script. Encode it first and the angle brackets become &lt; and &gt;, so the browser displays the text harmlessly instead of executing it. The five characters that matter most for this — &, <, >, ", and ' — are exactly the ones the default encoding always handles.

Tips and common mistakes

  • Always encode the ampersand first. When encoding by hand, convert & before the others; otherwise you can double-encode and turn &lt; into &amp;lt;. This tool handles ordering for you, but it is a classic manual error.
  • Encode for the right context. Entity encoding protects content placed in HTML text and attribute values. Data going into JavaScript, URLs, or CSS needs its own escaping — entities alone are not a universal sanitiser.
  • Prefer named entities for readability. Use names where they exist; reach for numeric forms only for characters without a named version, or when you specifically need hex.
  • Do not over-encode plain text. "Encode all chars" bloats your output and hurts readability; leave it off unless you have a specific reason.

Privacy

Encoding and decoding both run locally in your browser. Whatever you paste — including user data you are sanitising — is processed on your device and never uploaded or stored. The tool works fully offline.

Frequently Asked Questions

{# Alpine.js — self-hosted. (The previous jsdelivr CDN tag had a stale SRI integrity hash, so the browser refused to run it and window.Alpine was never defined — silently breaking every FAQ accordion and Alpine tool.) #}