HTML Entity Encoder & Decoder

Critical (must encode)

Punctuation and typography

Math and symbols

× (multiply)  ×    ×
÷ (divide)    ÷   ÷
± (plus/min)  ±   ±
≈ (approx)    ≈    ≈
≠ (not eq)    ≠       ≠
≤ (less eq)   ≤       ≤
≥ (greater)   ≥       ≥
∞ (infinity)  ∞    ∞
→ ← ↑ ↓       → ← ↑ ↓

The threat

Cross-site scripting (XSS) is when attackers inject JavaScript into your page. If user input contains <script>alert(1)</script> and you render it directly, every visitor runs the attacker's code. HTML entity encoding neutralizes this — the browser sees text instead of markup.

Context-specific encoding

Different contexts need different escapes:

• HTML body: escape < > &
• HTML attribute: additionally escape " '
• Inside <script>: use JSON.stringify; HTML escaping insufficient
• URL parameters: use encodeURIComponent, not HTML entities
• CSS values: CSS-specific escaping, not HTML entities

Modern frameworks do this for you

React, Vue, Angular, Svelte all auto-escape by default — <div>{userInput}</div> is safe. The danger is dangerouslySetInnerHTML (React), v-html (Vue), @html (Svelte) — they bypass auto-escaping. If you must use them, sanitize with DOMPurify first.

Common XSS patterns blocked by encoding

# Attack input
<script>alert("XSS")</script>
<img src=x onerror="alert('XSS')">
javascript:alert('XSS')

# After HTML entity encoding (rendered as text)
&lt;script&gt;alert("XSS")&lt;/script&gt;
&lt;img src=x onerror="alert('XSS')"&gt;

Note: encoding doesn't help with javascript: URLs in attributes — for those, validate the URL scheme separately.

CSP as defense in depth

Even with proper encoding, add a Content Security Policy (CSP) header. Content-Security-Policy: script-src 'self' blocks inline scripts entirely — even if XSS slips through encoding, it won't execute.

Does this support numeric entities like ©?

Yes. Both encoder and decoder handle named entities (©), decimal numeric (©), and hex numeric (© or ©).

Is this safe to use with sensitive content?

Yes. All processing happens in your browser. Verify in DevTools Network tab — no external requests are made when encoding/decoding.

Should I encode all non-ASCII characters?

No, with UTF-8 encoding (the modern default), non-ASCII characters like Korean or emoji can appear directly. Only escape the five HTML-significant characters (< > & " '). Force-encoding all non-ASCII just bloats your HTML.

What's the difference between ' and '?

Both produce '. ' is a named entity defined in HTML5 (not in HTML4). For maximum compatibility with very old systems, use '. In practice, all modern browsers accept both.

Do I need to encode characters inside <textarea>?

Yes — textarea is a content element, not a "raw text" element. < inside textarea must be encoded as < for correct rendering. <script> and <style> are exceptions (raw text elements).

Are HTML entities the same as URL encoding?

No, they're different. HTML entities (<) are for embedding in HTML. URL encoding (%3C) is for embedding in URLs. Don't mix them — wrong context produces double-encoded or broken output.

Which characters actually need encoding?

In HTML body text, the ampersand and the less-than sign are the ones that genuinely break parsing. Inside attribute values you also need to encode whatever quote character delimits the attribute. The greater-than sign is encoded by convention rather than necessity, which is why you see it escaped even where it would be harmless.

Is entity encoding enough to prevent XSS?

Only in the right context. Encoding is context-dependent: what is safe in body text is not sufficient inside a script block, a style block, an event handler attribute, or a URL. Treating entity encoding as a universal defence is a well-documented way to ship a vulnerability.

What is the difference between named and numeric entities?

Named entities such as & are readable but limited to a defined list. Numeric entities such as & work for any character in Unicode. Numeric is the safer choice for unusual characters, and named is easier for a human to read in source.

Do I still need entities for accented and non-Latin characters?

Not if the page declares UTF-8, which every modern page does. Encoding them was a workaround for the days of ambiguous character sets, and doing it today just makes the source harder to read.