HTML Escape & Unescape: Entity Encoder
Escape raw HTML for safe display and decode entities back to text, bidirectionally and in real time, entirely in your browser.
Escape raw HTML for safe display and decode entities back to text, bidirectionally and in real time, entirely in your browser.
Some online tools decode entities by assigning your text to a live element's innerHTML, which parses it as markup: a pasted <img onerror=…> executes on the spot. This tool never does that.
<textarea>: a textarea's content is RCDATA in the HTML specification, meaning the parser decodes character references but never creates elements from it. That gives full coverage of every named and numeric entity with no execution path, and the element is never attached to the page.Sanitize raw user input from forms, comments, and text areas before storing it in your database to prevent Cross-Site Scripting (XSS) injection attacks across your application.
Safely encode complex HTML strings so they can be embedded directly within JSON API payloads without breaking string boundaries or disrupting downstream parsers.
Convert raw HTML elements into secure, escaped entities so they render visibly as code blocks in the DOM rather than being interpreted and executed by the browser engine.
Test the sanitizer's regex capabilities. Click the templates below to load payloads directly into the workspace.
If an online tool sets your pasted text to a live element's innerHTML in order to read the browser's parsed entities, inline event handlers (like onerror) within your text can immediately execute. Layerbit escapes with pure string replacement and unescapes through a detached textarea, whose content is RCDATA: the parser decodes character references but never creates elements from it, so nothing can run.
The extended profile (default) escapes ampersands (&), less than/greater than symbols (< >), double/single quotes (" '), forward slashes (/), backticks (`), and equals signs (=). The essential profile escapes only the first five, and a third profile additionally turns every non-ASCII character into a hex reference.
No. While this tool is perfect for ad-hoc preparation and debugging, enterprise applications should never trust client-side input exclusively. You must always sanitize strings on your backend server before executing SQL inserts or NoSQL document updates.
HTML escaping replaces characters that carry structural meaning with entity references. There are five that matter, and one ordering rule that catches people out:
& → & — must be replaced first, or you re-escape the semicolons of your own entities and produce &lt;, which renders visibly as <.< → < and > → > — otherwise your value starts or ends a tag." → " and ' → ' — these end a quoted attribute value. Prefer the numeric ' over ', which was not in HTML 4 and is unrecognised by some legacy parsers.Get that right and a value is safe in exactly one context: as text between tags. Everywhere else needs different handling, which is the subject of our guide on contextual output escaping.
<input value={{ x }}> is unsafe even when escaped, because an unquoted value ends at the first space. A payload of x onfocus=alert(1) autofocus contains none of the five characters and adds an event handler. Always quote attributes.
<script>HTML escaping is the wrong tool here and corrupts the data. Worse, the literal text </script> ends the block even inside a JavaScript string, because the HTML tokeniser runs before the JS parser. Serialise as JSON into a data attribute instead.
hrefEscaping produces well-formed HTML and does not help: javascript:alert(1) contains no character that escaping touches. The defence is a scheme allowlist — accept http:, https:, mailto: and reject the rest.
A persistent anti-pattern is escaping values as they arrive and storing the escaped form. It fails for three reasons worth knowing:
& instead of &.&lt; on the page — and the usual "fix" is to disable escaping in that template, which removes the real protection.Store exactly what the user typed; escape at the moment of rendering, for the destination it is rendering into. This tool's unescape direction is genuinely useful for diagnosing the double-escaping case: paste the mangled output and you can see how many rounds of escaping it went through.
These solve different problems. Escaping renders a value as inert text, so <b>hi</b> displays as those literal characters — correct for usernames, titles and comments. Sanitising parses the value as HTML and strips everything not on an allowlist while keeping the rest live — correct only when users are meant to submit formatting. If you need sanitising, use a maintained library such as DOMPurify and never a regular expression: HTML is far too irregular for pattern matching, and every hand-rolled tag stripper has been bypassed via malformed markup that browsers helpfully "correct" into something executable.
©, and 😀 all round-trip.