Online HTML Entity Encoder/Decoder: Safely Handle Special Characters

What Is HTML Entity Encoding

HTML entity encoding converts special characters to safe strings starting with & and ending with ;. It enables safe display of special characters in HTML. Need to encode a string right now? Our HTML entity encoder converts characters in your browser with no upload.

Common HTML Entities

Why You Need HTML Entity Encoding

1. Prevent XSS attacks: User input like <script> becomes safe text
2. Display special characters: Show <, >, & in HTML content
3. Internationalization: Display special symbols and characters
4. Template engine output: Ensure dynamic content renders safely
5. Email templates: HTML emails need stricter escaping
6. Rich text editors: Safely save and display user content

XSS Prevention Example

Dangerous Unescaped Output

<!-- User input: <script>alert('XSS')</script> -->
<div>{{ user_input }}</div>

<!-- Rendered (DANGEROUS!) -->
<div><script>alert('XSS')</script></div>

Safe Escaped Output

<!-- User input: <script>alert('XSS')</script> -->
<div>&lt;script&gt;alert(&#39;XSS&#39;)&lt;/script&gt;</div>

<!-- Rendered (SAFE) -->
<div>&lt;script&gt;alert('XSS')&lt;/script&gt;</div>

Entity encoding covers HTML body / attribute contexts only. Inside a <script> string or a URL query you need that context's escaper — otherwise the "protection" does nothing.

How to Use an Online Tool

Using ToolVault's HTML Entity Encoder/Decoder:

1. Enter text to encode or decode
2. Encode modes: Special (default big five) / All / Named first
3. Decode modes: Decode all (named table + numeric), Named only, or Peel all layers — walks < style double-encoding down to plaintext
4. For fullwidth→ASCII normalization, use the html-entity-enhanced alias (Named-first default + fullwidth toggle)
5. Core htmlEntityDecode shares the named table with UI Decode all; multi-layer peeling uses decodeHtmlEntitiesFully

Text copied from CMS fields, email HTML, or second-pass templates is often half-encoded already. Peel all layers first to see the real characters, then encode once at the final render boundary.

HTML Escaping in Code

JavaScript

// Encode
function escapeHtml(text) {
  const map = {
    '&': '&',
    '<': '&lt;',
    '>': '&gt;',
    '"': '&quot;',
    "'": '&#039;'
  };
  return text.replace(/[&<>"']/g, m => map[m]);
}

// Decode (single pass; loop or use a dedicated peel for double-encoding)
function unescapeHtml(text) {
  const map = {
    '&amp;': '&',
    '&lt;': '<',
    '&gt;': '>',
    '&quot;': '"',
    '&#039;': "'"
  };
  return text.replace(/&amp;|&lt;|&gt;|&quot;|&#039;/g, m => map[m]);
}

Python

import html

# Encode
text = '<script>alert("XSS")</script>'
encoded = html.escape(text)
# Output: &lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;

# Decode (html.unescape peels nested named/numeric entities aggressively)
decoded = html.unescape(encoded)
# Output: <script>alert("XSS")</script>

Named vs numeric: which to emit and when

Named entities (&,  ) read better in source; numeric forms (&,  ) are unambiguous and always valid — including in XML, where named entities beyond the five predefined ones do not exist. The rule by output target: HTML5 documents accept both; XHTML/XML wants numeric or the predefined five; emails and older CMS fields are safest with numeric because entity tables vary. A subtle bug class: double-encoding — & appears when a pipeline encodes already-encoded text; the decoder sees & and renders a literal & on the page. The fix is always decode-to-canonical first, then encode once at the boundary. The tool's "Peel all layers" mode exists for exactly that cleanup step.

The five contexts that each need different escaping

HTML body text, attribute values (quotes matter), URLs (percent-encoding, not entities), JavaScript string literals (backslash escaping), and CSS url() — five different grammars, five different escapers, and the classic injection bugs come from using the wrong one. Entity encoding is for the first two only. " in an attribute prevents breaking out of the quote; the same entity in a script block does nothing, because script content is not entity-decoded by the parser. Choosing the escaper by context — not by convenience — is the entire discipline of output encoding.

For reserved characters in query strings, use the URL encoder instead of stuffing HTML entities into a query.

When NOT to escape

Markdown processors, template variables marked safe (dangerouslySetInnerHTML, {!! !!} in Blade), and email subject lines all have contexts where entity-encoding produces visible garbage (& rendered to users). The pattern for mixed content: escape at the last possible moment (rendering), not at storage — stored-encoded data double-encodes on every edit cycle and becomes archaeology after three rounds.

Where this meets JSX / React

React auto-escapes JSX interpolations, so most list rendering does not need hand-rolled entities. The danger zones are dangerouslySetInnerHTML and concatenating HTML strings into attributes. If you are migrating static markup into components, run HTML to JSX first to normalize attributes, then decide where entities or sanitization are still required.

Fullwidth paste and CJK cleanup

Copying from Word, PDFs, or some IM clients often injects fullwidth ASCII (＜div＞) and ideographic spaces. Those characters are not the HTML specials your escaper looks for, so a naive encode leaves them looking “almost right” until a parser chokes. On the enhanced tool page, enable fullwidth→ASCII normalization before encode or decode so the five specials and named-entity table see the halfwidth forms you actually meant. Pair that with Peel all layers when the same paste has already been entity-encoded once by an upstream CMS.

FAQ

What's the Difference Between HTML Encoding and URL Encoding?

HTML encoding handles special characters in HTML documents (< → <). URL encoding handles special characters in URLs (space → %20). They solve different problems.

Why Must & Be Escaped First?

& is the starting character of HTML entities. If & isn't escaped first, subsequent escape sequences get misinterpreted. For example: < without escaping & would be treated as an entity itself.

Does React Auto-Escape?

React automatically escapes variables in JSX. But if you use dangerouslySetInnerHTML, no escaping occurs — you must handle it manually.

Decode all vs Peel all layers?

Decode all runs one pass (< → <). Peel all layers repeats until stable (ending at <). Use the latter when debugging double-encoded paste; use the former for a normal encode/decode round-trip.

Triage notes

"Five contexts, five escapers" is the article's core discipline: HTML body, attributes, URLs, JS strings, and CSS url() each have their own escaper, and entity encoding covers only the first two — " inside a script block defends against nothing, because the parser does no entity decoding of script content. The double-encoding fix is written as an iron rule: decode to canonical form first, then encode once at the boundary; the "three places you shouldn't escape" supply the same rule from the opposite side — data escaped at storage time doubles its encoding on every edit cycle and turns archaeological after three rounds, so escaping belongs at the last moment, not at storage. The peel-all-layers mode mirrors a real workflow: text copied out of CMSs and email is frequently half-encoded, so peel first to see the actual characters, then fix — otherwise each fix compounds the mess.

Written and maintained by ToolVault. Related tools: HTML entity encoder, URL encoder, HTML to JSX. More developer tools at the homepage.