HTML Escape / Unescape
β‘ Runs locallyπ No uploadsπ Free, no sign-up
HTML escaping solves one concrete problem: a handful of characters mean something special inside HTML, so you cannot drop them into a page as plain text. The less-than sign < opens a tag, > closes it, & starts an entity reference, and quotes delimit attribute values. If you want a page to literally display a snippet like <div>hello</div>, the browser will not show that text β it will try to parse it as an actual div element. Escaping swaps each special character for a safe placeholder the browser understands: < becomes <, > becomes >, & becomes &, and quotes become " and '. At render time the browser converts those entities back into the original characters for display, but it never treats them as markup. That is also the first line of defense against cross-site scripting (XSS): if user input is stitched into a page without escaping, an attacker can submit <script> and have code run in someone else's browser; escaped, the same input is inert text.
Three everyday jobs cover most real use. First, publishing code in a blog post or documentation page: paste HTML or JavaScript here, escape it, then drop the result inside <pre><code> or a rich-text editor so readers see the code verbatim instead of the browser executing or swallowing it. Second, building templates and attribute values during development: before inserting a user nickname, a comment, or a search keyword into an attribute such as title="...", escape quotes and angle brackets so the value cannot break out of the attribute and corrupt the page structure. Third, debugging encoding bugs in production: when an API returns double-encoded output like &lt;, or a page visibly renders the four characters <, unescape the string here to decode entities back to the original text and see immediately which layer escaped one time too many or one time too few.
Know the boundaries before you trust the output. Order matters when escaping: & must be replaced first. If you escape < before &, the freshly generated < gets escaped again into &lt;, and the page ends up displaying the literal text < β the classic double-escaping bug. Decoding has the mirror-image rule: decode exactly one layer. &lt; should become <, not <; decoding twice in a row is how sanitized input quietly turns back into live markup. Numeric entities come in decimal (<) and hexadecimal (<) forms and browsers accept both; this tool's unescaper handles both, plus a practical set of named entities such as , © and —. An unknown named entity is left untouched rather than guessed at. Escaping non-ASCII characters into numeric entities is only worth it for legacy systems, HTML email, or strict ASCII channels β on a modern UTF-8 page it just bloats the output and hurts readability, so that option stays off by default.
One security caveat is worth stating plainly: HTML escaping only protects content placed in HTML element or attribute context. It is not a universal sanitizer. Content that lands inside a <script> block needs JavaScript string escaping, a value placed in an href needs URL validation and encoding, and CSS contexts have their own rules β escaping once with the wrong encoder gives a false sense of safety. Used in the right context, though, it is the cheapest security control you will ever apply. Every conversion here runs locally in your browser with plain string replacement; this page has no backend endpoint and makes no network requests with your input, so pasted code, comments, and user data never leave your device.
How to use
- Paste HTML code or plain text into the input (or click Load example to try it)
- Tick Escape quotes, Escape slash, or Escape non-ASCII as needed, then click Escape
- Click Unescape to decode <, <, < and named entities back to plain text
- Copy the result into your editor or template, or use Swap input / output to chain conversions
FAQ
What is the difference between HTML escaping, URL encoding, and Base64?
They solve different problems. HTML escaping turns <, > and & into entities like < so content displays safely inside a web page and cannot inject markup β that is the anti-XSS use. URL encoding (percent-encoding) turns characters into %XX sequences so a string can travel inside a web address. Base64 encodes binary data as text so it can move through text-only channels. Using the wrong one does not work: URL-encoding a comment does not stop it from breaking out of an HTML attribute.
Why does my page show < instead of < after escaping?
That is double escaping. The content was escaped twice, so the & inside < was escaped again into &lt;, and the browser faithfully displays < as text. Unescape the result once here to confirm it returns to normal, then fix the pipeline so escaping happens exactly once, at the layer that finally assembles the HTML β not at storage or transport time.
When should I escape quotes, slashes, or non-ASCII characters?
Escape quotes whenever content can land inside an attribute value such as title="..."; an unescaped quote closes the attribute early and is a classic injection point, so it is on by default. Escaping slashes (/ as /) is extra hardening that only some legacy filters and strict gateways need. Non-ASCII escaping converts Chinese text, accents, and emoji into numeric entities β useful only for ASCII-only systems like older email infrastructure; on a UTF-8 page it just inflates size.
Which entity formats can the unescaper decode?
Three kinds: named entities (<, >, &, ", , ©, — and other common names), decimal numeric entities (<), and hexadecimal numeric entities (<). Decoding is deliberately single-layer β &lt; decodes to <, never straight to < β so you cannot accidentally reassemble live markup. Unknown named entities are passed through unchanged instead of being guessed.
Is my code or text uploaded anywhere?
No. Escaping and unescaping are pure local string operations in your browser; this page has no backend and sends no network requests with your input. Code snippets, user comments, and configuration fragments are safe to paste, and closing the tab leaves nothing behind.