HTML Entity Encoder & Decoder at a glance
- What it does
- Convert characters to HTML entities or decode entities back to text. Escape user content safely and fix mojibake in feeds and CMS exports.
- Where it runs
- Entirely in your browser — no data is uploaded
- Works offline
- Yes, once the page has loaded
- Cost
- Free, with no account and no usage limit
- Category
- Developer & Code
How to use the entity converter
- Paste your text or HTML into the input panel.
- Encode to replace special characters with their entity equivalents, ready to drop into a template or an email body.
- Decode to turn
<-style sequences back into the characters they represent - useful for reading a CMS export or a scraped feed. - Copy the output when it looks right.
The five that always matter
| Character | Named entity | Numeric | Escape it when |
|---|---|---|---|
| < | < | < | Always - it opens a tag. |
| > | > | > | Always, for symmetry and safety. |
| & | & | & | Always - it starts an entity. |
| " | " | " | Inside a double-quoted attribute value. |
| ' | ' | ' | Inside a single-quoted attribute value. |
Note that ' is valid in XML and HTML5 but was not defined in HTML4, so the numeric ' is the safer choice for the apostrophe.
Escaping is context-dependent
Entity encoding protects HTML text nodes and attribute values. It is not a general-purpose sanitiser, and applying it in the wrong context provides no protection at all.
- In HTML text and attributes - entity encoding is exactly right.
- Inside a
<script>block - the HTML parser does not decode entities there. You need JavaScript string escaping, ideallyJSON.stringify. - Inside a URL attribute such as
href- you need percent-encoding as well, and you must rejectjavascript:schemes. - Inside CSS - CSS has its own escaping rules; entities do nothing.
Use this tool for authoring and debugging. In production, escape user input server-side with your framework's context-aware helper - React, Rails, Django and Laravel all escape by default, and the vulnerabilities come from the places you deliberately opt out.
Fixing entity soup and mojibake
Two failure modes look similar and have different causes.
Double-escaped output - the page literally shows &lt;p&gt;. Something escaped text that was already escaped. Decoding twice with this tool tells you how many layers there are.
Mojibake - é instead of é, or ’ instead of a curly apostrophe. That is not an entity problem: UTF-8 bytes were read as Latin-1 somewhere. The fix is to correct the encoding declaration, usually a missing <meta charset="utf-8"> or a database column in the wrong collation.
The characters you cannot see
A category of entity exists purely to control layout, and these cause a disproportionate number of hard-to-diagnose bugs because they are invisible in an editor.
| Entity | Character | Effect |
|---|---|---|
| Non-breaking space | A space the browser will not wrap at. Useful between a number and its unit. |
­ | Soft hyphen | Invisible unless the word needs breaking, then it becomes a hyphen. |
‍ ‌ | Zero-width joiner/non-joiner | Controls ligatures in Arabic and Indic scripts, and joins emoji into compounds. |
    | En and em spaces | Typographic spacing of a fixed width. |
The one that causes trouble is . Text pasted from a word processor or a website is full of them, and they compare as different from an ordinary space — so a search fails, a form validation rejects the input, or a database lookup returns nothing, for a string that looks identical on screen. Decoding text here reveals them.
Entities in HTML email
HTML email is the one context where entity encoding is still routinely necessary rather than optional. Email clients vary enormously in how they handle character encoding, and several older ones do not honour a charset declaration at all.
The practical rule for email templates: entity-encode anything above plain ASCII — accented characters, curly quotes, dashes, currency symbols and the degree sign. A £ sign that renders as £ in Outlook is the classic symptom, and using £ avoids it entirely.
Emoji are the exception: they have no named entities and are better handled by declaring UTF-8 properly, since clients that cannot render them will not be helped by a numeric reference either.
Frequently asked questions
Not on a modern page. If your document declares UTF-8, you can write café and 🎉 directly. Entities remain useful for invisible characters such as and for contexts where you cannot rely on the encoding, such as some email clients.
It prevents injection into HTML text and attribute contexts, which is the most common case. It does nothing inside script blocks, style blocks, or URL attributes, each of which needs its own escaping.
A non-breaking space: it renders as a space but the browser will not wrap a line at it. Useful between a number and its unit, or in a name you want to keep together. Long runs of them to fake indentation are a sign the markup wants CSS instead.
Named entities are readable and fine in HTML. Numeric entities work in XML too, where only five names are predefined. If your output might be consumed as XML, prefer numeric.
Nothing you enter here leaves your browser
HTML Entity Encoder & Decoder does its work in JavaScript running on your own device. The page loads once, and after that there is no upload step and no server involved — which matters here because API responses, tokens and configuration files are exactly the kind of thing that should not be posted to someone else’s server for formatting.
You can verify this rather than taking our word for it: load the page, disconnect from the internet, and the tool keeps working. Our privacy policy sets out what is and is not collected, and this guide explains why the distinction matters.