HTML Entity Encoder Online

How to Encode HTML Entities Online

1. Paste Your Text: Drop raw text, code snippets, or user-supplied strings into the Input (Plain Text) field. The encoder runs entirely in your browser — nothing is uploaded to a server.
2. Pick the Encoding Scope: Default encodes only the five characters that MUST be escaped in HTML body context — <, >, &, ", '. Toggle "encode non-ASCII" to also entity-encode characters above U+007F (accents, CJK, emoji) for legacy systems that don't speak UTF-8.
3. Choose Named vs Numeric (Optional): Named references (&, ©) are readable; numeric references (&, &) work in every parser including XML and ancient mail clients. Numeric is the safer default for cross-system pipelines.
4. Copy from the Output Pane: The Encoded Output updates as you type. Copy and drop straight into your HTML source, template, or CMS.

Why Encode HTML Entities?

Five ASCII characters — <, >, &, ", ' — carry structural meaning in HTML. If you drop them into a page unescaped, the browser treats them as markup, and at best your page renders wrong; at worst, a hostile string injects a <script> tag and you have a cross-site scripting (XSS) bug. Entity encoding swaps each reserved character for a &name; or &#nnnn; reference that the parser displays as text instead of interpreting as syntax. The OWASP XSS Prevention Cheat Sheet lists these five characters as the minimum mandatory set for HTML body context.

• XSS defense for user-generated content — Comment fields, profile bios, search boxes, and chat transcripts must be entity-encoded before being inserted into a page. Encoding <script>alert(1)</script> to <script>alert(1)</script> neutralizes the injection — the browser shows the literal text instead of executing it.
• Displaying code samples — Documentation, blog posts, and Stack Overflow-style Q&A all need to render HTML/XML/JSX source as visible text. A snippet like <div class="hero"> only displays if you encode it as <div class="hero">.
• Safely embedding strings in attributes — Double-quoted attribute values break the moment the content contains an unescaped ". Encode quotes to " (or ") so values like title="She said \"hi\"" survive intact. URLs in href also need & encoded as & to prevent the parser from looking for an entity reference inside the query string.
• CMS and email templates — Email clients have wildly inconsistent named-entity support. Numeric references (© instead of ©) render reliably across Gmail, Outlook, Apple Mail, and Yahoo where named entities sometimes don't.
• JSON, RSS, and feed payloads embedded in HTML — When an XML/RSS feed or JSON-LD block sits inside an HTML page, reserved characters in field values must be escaped to keep the surrounding parser happy.
• Round-tripping content through legacy systems — Older databases, WordPress's wp_kses filter, and PHP htmlspecialchars() all assume entity-encoded input. Pre-encoding before storage avoids surprises on read.

Mandatory HTML Entities — The Core Five

Character	Named Entity	Decimal	Hex	Notes
& (ampersand)	&	&	&	Escape FIRST when encoding manually — otherwise you double-encode existing entities
< (less-than)	&lt;	&#60;	&#x3C;	Opens an HTML tag if left raw
> (greater-than)	&gt;	&#62;	&#x3E;	Closes a tag; less critical than < but escape for symmetry
" (double quote)	&quot;	&#34;	&#x22;	Required inside double-quoted attribute values
' (apostrophe)	&apos; (XHTML/HTML5 only) or &#39;	&#39;	&#x27;	&apos; is NOT defined in HTML 4 — use &#39; for max compatibility

Named vs Numeric vs Hex — Pick the Right Format

Format	Example	Coverage	Best For
Named reference	&, ©, —	~2,231 entities in HTML5 spec	Human-edited HTML, readability
Decimal numeric	&, ©, —	Any Unicode code point U+0001 to U+10FFFF	XML, RSS, legacy email, JSON-in-HTML
Hex numeric	&, ©, —	Same range as decimal, terser for high code points	Code generators, dense Unicode (emoji at U+1F600+)

All three forms produce identical rendered output. Named references existed in HTML 4 but the count exploded in HTML5 — ' is one example that XHTML 1.0 and HTML5 accept but HTML 4 does not. When in doubt, decimal numeric references work everywhere.

Frequently Asked Questions

Which characters MUST be escaped in HTML?

Five: <, >, &, ", and '. These are the OWASP-recommended minimum for the HTML body context. In attribute context, OWASP recommends a stricter rule — encode every non-alphanumeric character below U+00FF using &#xHH; format — because attribute parsers accept a wider range of breakouts. For everyday HTML body content, the five-character set is sufficient.

Is ' safe to use?

It depends on the doctype. ' is defined in XML, XHTML 1.0, and HTML5, but it was NOT defined in HTML 4. A page served as <!DOCTYPE html> (HTML5) renders ' correctly in every current browser. A page served as HTML 4.01 Strict/Transitional may render the literal text ' in older user agents. For maximum portability — especially when targeting old email clients, RSS readers, or legacy CMS pipelines — use ' (decimal) or ' (hex) instead.

Should I use named entities or numeric references?

Named references win on readability — — is obvious; — is not. Numeric references win on portability — they work in XML, JSON-in-HTML, and email clients that lack the HTML5 entity table. A reasonable rule: hand-written HTML uses named references for the common ~30 entities (&, <, >, ",  , ©, —, …, etc.); generated/machine output uses decimal numeric references for everything.

Is HTML entity encoding the same as URL encoding or XML encoding?

No — they're three different schemes for three different contexts.

• HTML entity encoding replaces reserved chars with &name; or &#nnnn; — for embedding text inside HTML content or attributes.
• URL percent-encoding (RFC 3986) replaces reserved chars with %XX — for query strings, paths, and form bodies. Use the URL encoder for that.
• XML encoding uses the same &/</>/"/' set as HTML5 but the named-entity table is much smaller (just those five). For arbitrary Unicode in XML, use numeric character references.

Picking the wrong scheme is a classic injection bug — entity-encoding a URL leaves % and ? exposed; URL-encoding HTML produces %3C instead of <, which the browser shows as literal text instead of a tag.

Does HTML encoding prevent XSS by itself?

For HTML body context — yes, encoding the five characters before insertion stops the canonical <script> injection. But XSS prevention is context-sensitive. If you're inserting user data into a JavaScript string, a CSS url(), an attribute name (vs value), or an unquoted attribute, HTML entity encoding alone is NOT enough — you need JS escaping (\xHH), CSS escaping (\HH), or, ideally, you should redesign so user data never lands in those positions. See OWASP's cheat sheet for the full context matrix.

What is double encoding and why does & show up?

Double encoding happens when text that's already entity-encoded gets encoded a second time. The first pass turns & into &. The second pass sees the literal & at the start of & and turns it into &. The browser then displays the literal text & instead of the intended &. Fix: encode raw text exactly once, immediately before insertion into HTML. If you must round-trip, decode fully before re-encoding, or use a templating engine (Jinja, Handlebars, React JSX) that auto-encodes on output and tracks encoding state.

Why does element.textContent = userInput look safe but innerHTML is dangerous?

In the DOM, textContent and innerText treat their input as plain text — the browser automatically escapes <, >, and & before insertion, so userInput = "<script>alert(1)</script>" shows up as visible text and never executes. innerHTML parses its input as HTML, so the same string injects a (dormant — modern browsers don't run script tags inserted via innerHTML, but <img onerror> and other event handlers still fire). Rule of thumb: prefer textContent for any string that started outside your code. If you absolutely need innerHTML, entity-encode the user portion first.

How does the encoder handle emoji and characters above U+FFFF?

Emoji like 😀 (U+1F600) and other Supplementary Plane characters are encoded as a single numeric reference using the full code point — 😀 decimal or 😀 hex. The HTML spec accepts code points up to U+10FFFF in numeric references. The encoder does NOT emit UTF-16 surrogate pairs (��) because the HTML parser interprets those as two separate (invalid) code points. JavaScript's internal string representation uses surrogate pairs, but that's a JS implementation detail — for HTML output, emit the single code point.

Will the encoded text decode back to the original?

Yes — entity encoding is fully reversible. Paste the output into the HTML Entity Decoder to recover the source. This round-trip is useful for verifying you haven't double-encoded, for extracting plain text from scraped HTML, or for debugging entity issues in a CMS pipeline.

---

Related developer tools: HTML Entity Decoder · URL Encoder · URL Decoder · Base64 Encoder/Decoder · JSON Formatter · JWT Decoder