acento.io
Text utility

HTML Entities Encoder / Decoder

Encode special characters to HTML entities or decode them back to plain text — fully client-side, nothing leaves your browser.

By Carlos Suárez , Systems engineer
Last updated:

What this HTML entities encoder/decoder does

This English-language tool lets you escape special characters into safe HTML entities — or reverse the process and recover the original text. Encode mode converts the five critical characters (&, <, >, ", ') plus an optional pass for all non-ASCII code points into numeric entities. Decode mode handles named entities like &amp;, &nbsp;, and &copy;, as well as decimal (&#160;) and hex (&#xA0;) forms. Unicode 15.1 added 627 new characters in 2023, so non-ASCII encoding is increasingly relevant for internationalised content. The tool is honest about its scope: it covers the common named entities and all numeric references without bundling the full HTML5 list of ~2,000 names, which is rarely needed in practice and adds unnecessary weight to any app. Best of all, it runs entirely in your browser — 100% client-side — your data never leaves your browser. No uploads, no tracking, no server logs.

Features

  • Five-character encode pass. Always escapes &, <, >, ", and ' — the characters that break HTML structure and open XSS vectors in templates.
  • Encode all non-ASCII. Optional mode converts every character outside the ASCII range to a decimal numeric entity, safe for environments that can't reliably transmit Unicode — such as legacy email clients.
  • Full decode support. Decodes named entities (&copy;, &nbsp;, &eacute;…), decimal references (&#233;), and hex references (&#xE9;) in a single pass.
  • Scope-honest approach. Covers the entities you actually encounter day-to-day without the ~2,000-entry HTML5 named-entity table. No bundle bloat, no confusion. If you need slug-safe output after decoding, the [URL slug generator](/en/slugify/) pairs well here.
  • One-click copy. Output is selectable and copyable with a single button tap — no fussing with manual selection, even for large blobs of markup.
  • Privacy by design. The encoder and decoder run entirely in JavaScript in your browser tab. No text is sent to any server, which matters when you're pasting template fragments containing credentials or PII.

How to use the HTML entities encoder/decoder

Paste your text, pick a mode, and the output updates instantly. Three common workflows are covered below.

  1. Pick a mode. Select **Encode** to escape characters for safe HTML output, or **Decode** to convert entity references back to readable text.
  2. Paste your input. Drop raw HTML, a scraped string, or any text fragment into the input box. For example: <p>Café & jalapeño</p>.
  3. (Optional) Enable encode-all non-ASCII. Toggle **Encode all non-ASCII** when targeting environments that choke on multibyte characters — older email clients or HTML4 documents where &apos; isn't valid (use &#39; instead).
  4. Copy the output. Click **Copy** to move the result to your clipboard, ready to paste into your template, doc, or code editor.

Common use cases

  • Preventing XSS in HTML templates. Before interpolating user-provided strings into HTML, encode them here to verify your escaping logic matches the spec — especially useful when reviewing output from a templating engine you didn't write.
  • Extracting plain text from scraped HTML. When you fetch a page and the body contains entity-encoded text like &ldquo;Seattle&rdquo;, decoding it recovers the readable string for downstream processing or diff comparison. If you also need to compare two versions of a document, the [text diff](/en/text-diff/) tool complements this workflow.
  • Writing technical documentation. Docs that show HTML markup — tutorials, MDN-style references, Stack Overflow answers — need encoded angle brackets so they render as literal characters rather than parsed tags.
  • Email template development. Many email clients have incomplete Unicode support. Encoding non-ASCII characters as numeric entities (&#233; for é) guarantees consistent rendering across Gmail, Outlook, and older webmail clients.
  • Content management and CMS migration. Legacy CMS exports often double-encode or inconsistently encode special characters. Decoding and re-encoding a sample batch lets you verify the migration pipeline is idempotent before committing to a full run.

Frequently asked questions

Is my text sent to a server when I use this tool?

No. The encoder and decoder are implemented entirely in browser-side JavaScript. Your input never leaves your device — there are no network requests, no server logs, and no analytics that capture your text. You can verify this by opening your browser's network tab while using the tool.

Why doesn't this tool include all ~2,000 HTML5 named entities?

The full HTML5 named-entity list covers obscure mathematical and typographic symbols that almost no one needs day-to-day. Including it would roughly triple the JavaScript payload for minimal practical gain. Numeric entities (&#x1D11E; for 𝄞, for example) cover every Unicode code point without any lookup table.

What's the difference between &apos; and &#39;?

&apos; is valid in XHTML and HTML5, but it was not part of the HTML4 named-entity set. If you need a portable apostrophe entity that works across all HTML versions, use the decimal form &#39;. This tool uses &#39; when encoding single quotes for maximum compatibility, as noted in MDN — Date discussions of character handling in older parsers.

Do browsers require the semicolon at the end of a named entity?

The HTML spec requires the trailing semicolon (e.g. &amp;), but browsers are lenient and often parse &amp without it. Relying on that tolerance is risky — strict XML parsers and some sanitizers will reject the malformed entity. Always include the semicolon in code you write or generate.

How does encoding here relate to URL percent-encoding?

They solve different problems. HTML entity encoding makes characters safe inside HTML markup. URL percent-encoding (RFC 1738, first standardized in 1994) makes characters safe inside URLs. A character like é encodes to &eacute; in HTML but to %C3%A9 in a URL. URL-encoding adds roughly 200% overhead per non-ASCII byte, so it's worth using HTML entities instead whenever you're targeting HTML rather than a URL. The OWASP — Password Storage Cheat Sheet covers related output-encoding concerns in a security context.

Can I use this to clean up HTML before running a text diff?

Yes. Decode entities first to normalize the text, then paste the result into the [text diff](/en/text-diff/) tool. This avoids false positives where &mdash; and look different to a character-level diff but are semantically identical.