HTML Entity Encoder

Encode or decode HTML entities safely.

Encoding Mode
Scope
Options
Input
0 chars
Output
0 chars
Decode Options
Input
0 chars
Output
0 chars
Char Named Decimal Hex Description

How to use

  1. Paste your text or HTML snippet into the input area.
  2. Pick Encode to turn special characters into HTML entities, or Decode to do the reverse.
  3. Choose between named entities (&) and numeric ones (&).
  4. The output appears live and can be copied with a single click.
  5. Use the Swap button to push the output back as the new input.

Frequently asked questions

When should I use named versus numeric entities?

Named entities like © are easier to read; numeric like © work universally even in legacy XML where only a small set of names exist. Numeric is the safest choice for non-HTML contexts.

Which characters absolutely need encoding?

Inside HTML you must escape &, <, >, and inside attributes also " and '. Failing to escape these is a common source of XSS vulnerabilities.

Will the encoder handle emoji and astral characters?

Yes. Characters outside the Basic Multilingual Plane are encoded as their full unicode code point, for example &#128512; for the grinning face emoji.

Is my input uploaded anywhere?

No. Encoding and decoding happen locally in JavaScript, so secrets in your HTML stay on your device.

Why five characters rule HTML escaping

HTML cannot distinguish your content from its own syntax, so the characters that carry syntax must be escaped when they appear as data: &lt; for <, &gt; for >, &amp; for &, &quot; for double quotes and &#39; for single quotes inside attributes. Forgetting the ampersand is the subtle one: an unescaped & in a URL like ?a=1&copy=2 silently turns into the copyright symbol because &copy is a named entity even without its semicolon in lenient parsers.

Escaping is a security boundary, not cosmetics

Every cross-site scripting (XSS) attack is, at root, user input that reached the page without context-appropriate escaping. Encoding user-supplied text before rendering turns <script> into inert visible text instead of executable code. The rule professionals follow: escape at output time, in the encoding appropriate to the destination context (HTML body, attribute, URL and JavaScript each have different rules), and never trust that input was cleaned earlier.

Named vs numeric, and when to use neither

  • Named entities (&eacute;, &nbsp;) are readable but only a fixed list exists.
  • Numeric references (&#233; or hex &#x2014;) can express any Unicode character.
  • On modern UTF-8 pages, accented letters and symbols can simply be typed literally; reserve entities for the five syntax characters and for invisible characters like &nbsp; that would otherwise be unmaintainable.
  • Double-encoding is the classic bug in the other direction: encoding an already encoded string turns &amp; into &amp;amp; and renders as visible &amp;.

Entities you meet while reading source

  • &nbsp; is the non-breaking space: it glues "10 km" together across line ends, and in quantity it is the signature of content pasted from a word processor.
  • &copy; &trade; &reg; cover the legal symbols; &hellip; and the dash entities appear throughout typographically careful sites.
  • &#8364; and &euro; are the same euro sign by different routes... numeric and named forms are interchangeable where a name exists.
  • Seeing &amp;lt; in source means double encoding happened upstream: the page will display &lt; as text instead of a bracket.
  • An entity missing its semicolon may still render in lenient HTML but breaks in strict XML contexts... feeds and sitemaps want the full form.

Advertisement