Encode text to HTML entities or decode them back. Named, decimal and hex output, four encoding levels, XSS warnings. Free and runs in your browser.
This HTML entity encoder converts text into HTML entities and converts entities back into plain text, in one place, instantly. Paste a snippet containing <, >, & or quotes and get output that a browser will display as literal characters instead of parsing as markup. Choose named entities, decimal numeric references, hexadecimal references or a mixed strategy, and choose how aggressive the encoding should be. Everything runs in your browser — nothing is uploaded.
The two jobs it does are exact inverses. Encoding takes <div>Hello</div> and yields <div>Hello</div>, which renders on the page as the tag text rather than creating an element. Decoding takes entity-laden text out of a log line, an XML export or a database column and gives you back the original characters.
HTML has exactly five characters that carry structural meaning. If untrusted input containing them is written into a page unescaped, the browser cannot tell your markup from the attacker's — that is cross-site scripting in one sentence. Entity encoding removes the ambiguity by replacing each dangerous character with a token that means “display this glyph” rather than “begin a tag”.
The five that always need encoding in an HTML context:
& → & (decimal &, hex &) — encode this one first, or you will double-encode everything that follows< → < (<, <)> → > (>, >)" → " (", ") — essential inside double-quoted attributes' → ' (', ') — essential inside single-quoted attributesBeyond those, a useful reference set of named entities: for a non-breaking space, © ©, ® ®, ™ ™, € €, £ £, ¥ ¥, ¢ ¢, ° °, ± ±, × ×, ÷ ÷, ½ ½, ¼ ¼, ¾ ¾, — —, – –, … …, • •, § §, ¶ ¶, † †, ′ ′, ← ←, → →, ↑ ↑, ↓ ↓.
Every character can be written three ways, and the tool lets you pick which:
&, ©. Readable, but only defined for characters that have a name.&. A numeric character reference using the code point in base 10. Works for every Unicode character.&. The same thing in base 16, which is how code points are conventionally written.All three forms are equivalent to the parser. Numeric references are the safer default when output is consumed by something other than a full HTML parser, because named entities beyond the core five are not universally recognised in XML.
Encoding more than necessary bloats output and makes diffs unreadable; encoding less than necessary is a vulnerability. The tool offers four levels so you can match the context:
Entity encoding is contextual output encoding, and the context decides whether it works. Inside an HTML element or a quoted attribute value, it is correct and sufficient. Elsewhere it is not:
<script> — the HTML parser does not decode entities in a script data block, so entity encoding neither protects you nor round-trips. Serialise to JSON instead.javascript: decodes to javascript:, so an entity-encoded payload in href still executes. Validate the scheme, and use percent-encoding via the URL encoder for the query string.The tool flags patterns in your input that suggest an XSS attempt — on* event handler attributes, script and other dangerous tags such as iframe, object, embed and frame, and text that is already heavily entity-encoded (a classic evasion signal). Treat these as review prompts, not as a verdict. And encode on output, never on input: storing pre-encoded data guarantees double-encoding somewhere downstream, which is how &amp; ends up in your page titles. Pair this with a strong Content Security Policy so that a missed escape does not become an executed script.
Decoding accepts all three forms in the same input, so mixed text such as <p>café & bar</p> comes back intact.
It is the replacement of characters that have structural meaning in HTML — or that are hard to type — with escape sequences the browser renders as the literal glyph. < becomes <, so the browser displays a less-than sign instead of starting a tag.
Yes. Free, no account, no length limit, and it runs entirely in your browser.
At minimum &, <, >, " and '. Encode the ampersand first so you do not re-encode the entities you have just created.
Named entities like © are readable but exist only for a defined list of characters. Numeric references — decimal © or hex © — work for any Unicode code point. Browsers treat all three identically.
In HTML element and quoted-attribute contexts, yes. It does not protect JavaScript contexts, URL attributes such as href and src, CSS, or unquoted attributes — each needs its own escaping rules.
No. Store the raw value and encode at the point of output, using the encoding appropriate to that context. Encoding on input causes double-encoding and breaks searching, sorting and reuse in non-HTML contexts.
That is double encoding: an already-encoded string was encoded again. Decode it here until it stops changing, then fix the pipeline so encoding happens exactly once, at output.
Not on a UTF-8 page — they display correctly as-is, so minimal encoding is the right choice. Use extended or standard level only when output passes through a system that cannot handle non-ASCII bytes.
Yes. The decoder handles named entities, decimal references and hexadecimal references in the same input, in any combination.
No. Encoding, decoding and the security checks all run locally in your browser. Nothing is transmitted or stored.
HTML encoding (also called HTML entity encoding) converts special characters into their HTML entity equivalents so they display correctly in web pages rather than being interpreted as HTML markup. Characters like <, >, &, ", and ' have special meaning in HTML—they define tags, attributes, and entities. When these characters appear in user content, they must be encoded to prevent rendering issues and security vulnerabilities.
HTML encoding is one of the most important defenses against Cross-Site Scripting (XSS), the most prevalent web security vulnerability. When user input is inserted into a web page without encoding, an attacker can inject malicious HTML or JavaScript that executes in other users' browsers. Proper encoding neutralizes these attacks by ensuring special characters are treated as text, not code.
HTML encoding replaces special characters with named or numeric entity references:
| Character | Named Entity | Numeric Entity | Context |
|---|---|---|---|
| < | < | < | Opening tag delimiter |
| > | > | > | Closing tag delimiter |
| & | & | & | Entity start character |
| " | " | " | Attribute value delimiter |
| ' | ' | ' | Attribute value delimiter |
| / | / | / | Tag closing character |
| Space (non-breaking) | Preserved whitespace |
Encoding contexts matter: Different insertion points in HTML require different encoding strategies:
<, >, &, ", 'Using the wrong encoding for the context is a common source of XSS vulnerabilities.
HTML entities encode special characters that have meaning in HTML: < becomes <, > becomes >, & becomes &, " becomes ", ' becomes ' or '. Why important: prevents breaking HTML structure, avoids XSS (cross-site scripting) attacks, displays reserved characters literally, ensures proper rendering. Example: displaying code <script> without executing it. Two formats: named entities ( ), numeric entities (  decimal,   hex). Always encode user input before displaying in HTML to prevent security vulnerabilities.
XSS (Cross-Site Scripting) injects malicious scripts into pages. Without encoding: user input <script>alert("XSS")</script> executes as code. With encoding: <script>alert("XSS")</script> displays as text. Attack vectors: form inputs, URL parameters, cookies, database content. Defense layers: (1) Encode output (HTML entities), (2) Validate input (whitelist), (3) Content Security Policy headers, (4) HttpOnly cookies. Encoding alone not sufficient: use comprehensive XSS prevention, sanitize HTML if allowing markup, use frameworks that auto-encode (React, Vue). This tool helps encode untrusted content before rendering.
HTML encoding: for HTML content, encodes <>&"' to entities, used in HTML body/attributes, prevents HTML interpretation. URL encoding (percent encoding): for URLs, encodes space as %20 or +, special chars as %XX hex, used in query strings/paths, prevents URL parsing issues. Different contexts need different encoding: HTML entity: < for <, URL encoding: %3C for <. Don't mix: URL-encoded in HTML looks wrong (%20 displays as %20). When to use: HTML encoding in page content, URL encoding in hrefs/src attributes, both in JavaScript strings. This tool does HTML entity encoding; use separate tool for URL encoding.
Required in attribute values: double quote becomes " if using double-quoted attributes, single quote becomes ' if using single-quoted attributes, < becomes < (less common but safe), & becomes & (always). Example:
Unicode characters can be: (1) Used directly if UTF-8 charset: <meta charset="UTF-8">, no encoding needed. (2) HTML entities: é for é (named), é for é (decimal), é for é (hex). Modern approach: use UTF-8 directly, it's simpler and more readable. Encode entities only for: HTML special chars (<>&"), control characters, invisible chars, compatibility with non-UTF-8 systems. Emoji: use directly in UTF-8 or numeric entities 😀 😀. Right-to-left text: use proper HTML markup (dir="rtl"), not entities. This tool preserves Unicode by default, encodes only HTML special characters.
Encoding: converts special chars to entities, displays everything as text, no HTML tags work, safest for untrusted content, example: <b> → <b>. Sanitizing: allows some HTML, removes dangerous tags/attributes, permits formatting (<b>, <i>, <p>), blocks scripts (<script>, onclick), more complex. Use encoding when: displaying plain text, user input shown as-is, no formatting needed, maximum security. Use sanitizing when: allowing rich text editors, blog comments with formatting, markdown converted to HTML. Libraries: DOMPurify, sanitize-html for sanitizing. Never trust user HTML: always sanitize or encode. This tool does encoding (safest); use sanitizing libraries for rich text.
JavaScript: no built-in HTML encode. Manual: text.replace(/</g, "<").replace(/>/g, ">"). Libraries: DOMPurify, he, lodash escape. DOM method: textContent auto-encodes (safe), innerHTML doesn't (unsafe). Python: html.escape(text) built-in, or markupsafe.escape(). PHP: htmlspecialchars($text) or htmlentities($text). Java: StringEscapeUtils.escapeHtml4() (Apache Commons). Ruby: ERB::Util.html_escape() or CGI.escapeHTML(). C#: HttpUtility.HtmlEncode() or WebUtility.HtmlEncode(). Server-side encoding preferred: do before sending to browser. This tool for quick manual encoding and testing; use language built-ins in production code.
Double encoding: encoding already-encoded text, < becomes &lt;, displays as < not <. Fix: decode first, then encode. Wrong context: HTML encoding in JavaScript strings, needs JSON escaping too. Incomplete encoding: missing quotes or ampersands, still vulnerable. Over-encoding: encoding Unicode unnecessarily, makes text unreadable. Not encoding: forgetting to encode user input, XSS vulnerability. Encoding at wrong time: too early (breaks processing), too late (already executed). Inconsistent encoding: some fields encoded, others not. Testing: verify with XSS payloads: <script>alert(1)</script>, " onclick="...". This tool helps test encoding correctness before deploying.