HTML Entity Escaper
Escape text and code into HTML entities (ampersand, angle brackets, quotes) and unescape it back. Handy before pasting code into pre or code blocks.
Input
DirectionHow it works
- Escape mode replaces
&,<,>,"and'with&,<,>,"and'in a single pass, so the ampersand is never double-escaped - Unescape mode maps those five entities back to their plain characters
- The result is rendered inside a
<pre>block so entities stay readable without the browser decoding them - Character counts are reported before and after conversion
About HTML Entity Escaper
An HTML entity is a sequence that starts with an ampersand and ends with a semicolon — for example, < renders the < character. Browsers treat entities as literal characters instead of markup, which makes them the safe way to include reserved characters such as <, >, & and quotes in HTML text.
Escape code samples before pasting them into <pre> or <code> blocks so the tags inside your sample display as text instead of being parsed by the browser. Escaping also helps prevent XSS when user-generated content is inserted into a page, and it is a regular part of writing blog posts about code. Always escape the ampersand first, because every entity starts with one — escaping & last would turn the ampersand of an already-escaped < into &lt;. And beware of double escaping: escaping the same text twice produces entities such as &lt;, which browsers display literally instead of decoding.
Five characters, one pass
Exactly five characters are replaced: `&`, `<`, `>`, `"` and `'`. The implementation is a single regular expression pass with a replacement function, which is the detail that matters. The common advice to escape `&` first is a warning about sequential `.replace()` chains, where each call re-scans text the previous call already transformed — replace `<` first, then `&`, and the ampersand you just introduced as part of `<` gets escaped again, yielding `&lt;`. One pass with a lookup cannot double-escape, because no output is ever re-examined.
The apostrophe goes to the numeric reference `'` rather than the named `'`, which is deliberate and worth keeping: `'` is not defined in HTML 4, so older parsers and several XML-adjacent toolchains render it literally. `"` and the three named references are HTML 4 safe.
Escaping is context-dependent, and three contexts ignore it
In normal text content and in a quoted attribute value these five characters are sufficient — the quote forms are what stop a value breaking out of `attr="..."`. Inside `<script>` and `<style>` the content is raw text where character references are not decoded at all, so escaping there achieves nothing: `<` stays five literal characters. For JavaScript use `\u003c`, or let `JSON.stringify` handle it; for CSS use `\3c`. `<textarea>` and `<title>` are escapable raw text where entities are decoded normally, so plain escaping works. `<pre>` and `<code>` are ordinary text content, which is the case this tool is aimed at.
The URL case is a different encoding layer. HTML entities and percent-encoding are not interchangeable: an `&` separating query parameters should be `&` in the source so the parser does not begin an entity, and the browser then sends a literal `&` on the wire. Writing `%26` means something else again — a literal ampersand character. Reach for percent-encoding when building a URL in code, and for entities when embedding text in markup.
Why escaping is the last line of defence, not the first
Escaping neutralises markup syntax, and that is the whole of its scope. It does not help when the value lands in a script context, an unquoted attribute, a `javascript:` URL, a `style` attribute, or a URL the page will navigate to. An attacker controlling a value can still reach those positions with a payload containing none of the five characters. Output encoding per context is the real control; a Content Security Policy refusing inline script is what stops the rest.
The reason to prefer the DOM API is that `textContent` and `createElement` perform the encoding for you, correctly and for the context they are in, with no chance of forgetting a character or applying the wrong table. Use this escaper where you must produce markup as text — documentation, a `<pre>` block, a code sample, a log viewer — and prefer `textContent` everywhere else. Note also that the unescape direction only knows the five references it emits: ` `, `©` and numeric forms such as `'` pass through untouched, so it is a reverse of this escaper rather than a general entity decoder.
Frequently Asked Questions
How do I escape HTML special characters?
When do I need to escape HTML?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.