Escape HTML Safely — and Unescape It Back
HTML has five characters with built-in meaning: < and > delimit tags, & starts entities, and quotes delimit attribute values. Put them in a page as-is and the browser interprets them instead of displaying them — your code sample becomes invisible markup, your “AT&T” becomes a parsing oddity. The fix is entity encoding: < becomes <, & becomes &, and the browser displays the characters instead of obeying them. This tool converts both directions — encode text for safe display inside HTML, or decode entity-littered text back to readable characters — instantly and locally.
How to Use It
- Pick Encode or Decode with the tabs.
- Paste your text or markup; the converted result appears live.
- Encoding offers two levels: essential (the five structural characters — sufficient and recommended for most uses) or extended (also converts accented letters, dashes, arrows and symbols to named entities for legacy systems that mangle non-ASCII bytes).
- Copy the result with one click.
When You Need Encoding
- Displaying code on a web page: any HTML, XML or JSX sample must be entity-encoded or the browser will try to render it. This is the single most common use.
- User-generated content: names, comments and titles containing
<or&must be escaped before insertion into markup — the same operation that, done systematically, prevents script-injection (XSS) vulnerabilities. - Email templates and CMS fields that interpret HTML: literal angle brackets survive only as entities.
- XML payloads: the same five characters are reserved there too.
When You Need Decoding
The reverse problem is just as common: exports, feeds and scraped content arrive saturated with &, " and ', unreadable to humans and wrong for non-HTML destinations. Decoding restores the actual characters. The decoder here understands the full range of formats — named entities (é), decimal numeric (é) and hexadecimal numeric (é) — and resolves them all to the same “é”. A diagnostic worth knowing: text reading &lt; has been encoded twice; decode twice to recover the original, and find the pipeline stage doing the redundant encoding.
A Security Note, Stated Plainly
Entity encoding is a display-time tool and, applied consistently to untrusted input, a real security control — but this page is a manual utility, not a sanitization layer for your application. Use it to prepare samples, fix exports and debug encoding issues; inside actual codebases, escape output with your framework's templating functions, which apply exactly this transformation automatically and never forget. Everything you paste here is processed in your browser alone: markup from internal systems, draft content and user data never leave your machine, which is the correct standard for a tool that routinely handles exactly such material.
Quick Reference: the Entities You Will Actually Meet
A handful of entities account for nearly all real-world encounters, and recognizing them on sight saves constant lookups. & is the ampersand itself; < and > are the angle brackets; " and ' are the double and single quote; is the non-breaking space that mysteriously prevents line wraps; ©, ™ and ® are the legal symbols; and — is the long dash editors love. Anything numeric like ’ is simply a character referenced by its Unicode number — paste it into the decoder and see exactly which one.
Frequently Asked Questions
Which characters must always be encoded in HTML?
The structural five: < > & and both quote characters. Encoding just these makes any text safe to display inside markup — the “essential” mode covers exactly this set.
What is the difference between é and é?
None in result — both display “é”. One is a numeric reference to the Unicode code point, the other a named entity. The decoder resolves named, decimal and hexadecimal forms identically.
My text shows things like &quot; — what happened?
It was entity-encoded twice somewhere in a pipeline. Decode it twice here to recover the original text, then fix the stage that double-encodes.
Do I still need entities for accented characters on modern sites?
Generally no — UTF-8 pages display “é” and “→” directly, and essential-mode encoding is enough. The extended mode exists for legacy systems and email tools that corrupt raw non-ASCII bytes.