HTML Entity Encoder / Decoder: Escape Markup Without Guessing
An HTML entity encoder and HTML entity decoder solve a specific problem: turning characters like <, >, &, ", and non-breaking spaces into safe HTML entity form, then converting them back when you need readable text again. If you're embedding text into markup, copying HTML out of logs, or cleaning up CMS output, being able to encode HTML entities and decode HTML entities quickly saves time and prevents subtle rendering bugs.
This tool runs entirely in the browser, so conversion stays local. If you're pasting snippets from templates, user content, support tickets, or production logs, nothing needs to leave your machine. For a utility like this, that privacy angle matters more than marketing copy.
What's actually happening
HTML entities are character references. Instead of writing <, you can write <. Instead of &, you can write &. Browsers decode those references during HTML parsing and render the intended character.
There are two main forms:
- Named entities like
<,>,&,", and - Numeric entities like
<or<
An HTML entity encoder replaces characters with references so the browser treats them as text instead of markup. For example, <div class="note"> becomes <div class="note">. An HTML entity decoder does the reverse and turns Tom & Jerry back into Tom & Jerry.
This matters most when the same characters have structure in HTML. A literal <script> inside a text node is parsed as a tag. <script> is rendered as text. That's the core difference.
Using it
Paste text or HTML into the input, choose whether to encode or decode, and copy the result. Use encoding when you want characters like < and & rendered literally in HTML. Use decoding when you have escaped content such as <span>hello</span> and need to inspect or reuse the original text.
When you'd actually use an HTML entity encoder
- You need to show raw HTML in documentation, blog posts, or code examples without the browser interpreting it
- You're debugging CMS or WYSIWYG output that stores text as
,&, or' - You're generating HTML emails or templates and need to escape user-provided text before insertion
- You're reading logs, scraped markup, or API payloads that contain encoded entities instead of visible characters
- You want a fast HTML entities online utility that does local conversion instead of sending content to a server
Named vs numeric entities
Named entities are easier to read. © is more recognizable than ©. Numeric entities are more universal because they map directly to a code point and don't depend on remembering the entity name.
Both forms are valid for many characters. That also means round-tripping is not stylistically stable. If input contains  , a decoder returns the underlying character, and a later encode step may output or   depending on the implementation. The text value is preserved, but the original entity style usually is not.
Decoding is not sanitization
Decoding entities is a text conversion step, not a security feature. Turning <script>alert(1)</script> into <script>alert(1)</script> gives you executable markup if you then inject it into the DOM unsafely.
If you need to prevent XSS, use proper output encoding for the target context and sanitize untrusted HTML with a real sanitizer. An HTML entity decoder helps you inspect content. It does not make content safe.
Troubleshooting
Why did turn into a normal-looking space? — A non-breaking space is a different Unicode character from a regular space. It often looks identical in plain text, but line wrapping behavior changes in HTML and some editors hide the difference.
Why didn't decoding make my content safe to render? — Because decoding entities is not HTML sanitization. It only converts character references back into characters. Unsafe markup stays unsafe.
Why doesn't re-encoding produce the exact same entities I started with? — HTML entity encoder output is usually normalized. <, <, and < all represent the same character, so round-tripping preserves meaning, not the original entity style.
Do I need to encode quotes too? — In HTML text nodes, usually no. In attribute values, often yes. " itself is not an HTML entity; use " for double quotes when the context requires it.
Why are some Unicode characters left as-is instead of becoming entities? — Most Unicode characters can appear directly in HTML. Encoding is mainly required for characters with HTML syntax meaning, plus cases where you want compatibility or explicit escaping.
Why did my converted output clear after I edited the input? — The tool clears the previous result as soon as the input changes so swap and copy actions always reflect the current text. Run convert again to regenerate the output.