HTML Entity Encode

This tool encodes a string for safe inclusion in HTML by replacing special characters with HTML entities. Everything happens in your browser; nothing leaves your machine. For the inverse direction, see HTML decode.

Which characters need encoding

The encoding is context-dependent. Three contexts:

Text content (between tags)

<p>HERE</p>

Three characters must be encoded:

Anything else can be included as-is. Single and double quotes can be literal in text content because they don’t have meaning there.

Attribute values (inside double quotes)

<a title="HERE">link</a>

Four characters must be encoded:

The " matters here because it would close the attribute. If you’re using single-quoted attributes (title='HERE'), encode ' instead of ".

Inside <script> or <style>

Don’t HTML-encode. Those elements are special — entities aren’t decoded inside them. To put a < inside JavaScript, use a JavaScript string-escape form ('\\x3c'), not <.

What the tool above does

The tool encodes <, >, &, " (as ") and ' (as '), plus the invisible non-breaking space (as  ). That is the attribute-safe set, which is also safe in text content — over-encoding never breaks rendering. Everything else, including non-ASCII characters, is left as literal UTF-8.

Optional encodings

You can encode any character with HTML entities, but most don’t need it:

HTML before: A → B
HTML after:  A → B    (using named entity)
HTML after:  A → B  (using hex character reference)
HTML after:  A → B          (literal UTF-8 — also fine)

In the modern (UTF-8) web, you can put any Unicode character literally in HTML and the browser renders it correctly. Encoding non-ASCII is a holdover from when HTML files were ASCII-only and entities were the only way to include high-Unicode characters.

When encoding non-ASCII is useful:

• Emailing HTML through systems that mangle non-ASCII. Some email gateways re-encode UTF-8 incorrectly; entities survive.
• Pasting HTML into systems that strip high bytes. A few legacy contexts.
• Visibly distinguishing characters that look identical. — (em dash) and - (hyphen) look similar in many fonts; — is unambiguous in source.

For most modern web content, the right answer is “leave UTF-8 characters literal; encode only the five special characters as needed.”

Numeric character references vs named entities

Both work. & and & and & all decode to &. Differences:

• Named entities are limited to the 2,000+ predefined names. ©, €, ♥ are named; most Unicode characters aren’t.
• Numeric references work for any Unicode code point. 😀 works for an emoji that has no named entity.
• Code-readability. & is more readable than &. For the rare named entity, prefer the name.
• Decimal vs hex. Either works. Hex (—) matches Unicode’s standard documentation form and is preferred in modern code.

Encoding context affects the cure

A bug-prone case: encoding HTML once and then putting that encoded string into a JavaScript string in HTML. The browser parses the script tag without entity-decoding, so your script gets the literal entity, not the decoded character.

<!-- WRONG: -->
<script>const name = "&amp;hello&amp;";</script>
<!-- The script's `name` is the literal string "&amp;hello&amp;" -->

To put &hello& inside a JavaScript string in HTML, the right approach is to JSON-encode the value and put the JSON inside the script:

<script>const name = "&hello&";</script>      ← if quotes don't conflict
<script>const name = "&hello&";</script>  ← Unicode-escape if needed

Server-side templating engines often have an html_safe and js_safe distinction for exactly this. Pick the encoder that matches the destination context.

When to encode at all

The single most common HTML-encoding decision is preventing cross-site scripting (XSS). User-supplied content rendered in HTML must be encoded; otherwise an attacker can include <script> tags or event handlers (onclick=...) that execute in the user’s browser.

Modern templating frameworks (React, Vue, Angular, server-side templates like Jinja2 with autoescape) HTML-encode user content by default. If you’re hand-building HTML, the encoder is on you.

Common pitfalls

• Encoding inside <script> tags. Doesn’t help; entities aren’t decoded there. Use JavaScript escaping instead.
• Double-encoding. Encoding an already-encoded string yields & instead of &. Make sure you’re encoding the underlying string, not a transit form.
• Forgetting attribute encoding. <a title="<bad>"> is broken HTML. The < inside the attribute confuses the parser.
• Confusing HTML encoding with URL encoding. A & in a URL inside HTML needs both: URL-encoded as %26 if it’s a literal in a path, then HTML-encoded as & because the resulting URL is in HTML.
• Encoding non-ASCII unnecessarily. Modern HTML (UTF-8) doesn’t need it. Encoding é to é adds bytes for no benefit.

For the inverse direction, see HTML decode. For the entity reference, HTML entities. For URL encoding, URL encode.