HTML Entity Encoder & Decoder

About HTML Entities

Escaping turns <, >, &, quotes and non-breaking spaces into entity references so markup renders as visible text instead of being parsed as HTML. It is the basic defence against cross-site scripting when untrusted content is placed into a page.

Decoding uses the browser's own HTML parser, so every named entity it knows —  , ©, — and the numeric forms — resolves the same way it would on a real page. That makes it a quick way to read text scraped out of an HTML source or a CDATA block.

Which form to write is about what else will touch the markup rather than about the markup itself: all three mean the same to a browser. Named entities are the readable ones and exist for a couple of hundred characters; decimal and hexadecimal cover every character there is, which is what to reach for when something downstream may not know the names — XML, for one, defines only five of them. The apostrophe shows the seam: ' is XML and HTML5 but not HTML 4, so the named form writes it as '.

Where it helps

• Escapes the five characters that matter for injection, plus non-breaking spaces.
• Writes them as named, decimal or hexadecimal references — all equivalent to a browser, and only the numeric ones are safe for a parser that knows no names.
• Optional non-ASCII escaping produces output that is safe for strictly ASCII pipelines.
• Decoding covers the full named-entity set because it uses the browser parser.
• Includes a rendered preview so you can see what the escaped markup produces.

Limits

• Escaping is context-sensitive: entity escaping is correct for text nodes and attribute values, not for content inside <script> or a URL attribute.
• It is not a sanitiser — it makes markup inert, it does not filter tags out of markup you intend to keep.
• Round-tripping arbitrary text through decode then encode can normalise entities to a different but equivalent form.

Frequently asked questions

Is escaping entities enough to stop XSS?

For text placed into the body of a page, yes. Inside a <script> block, a style attribute, or an href, other rules apply and entity escaping alone is not sufficient.

What does the “reserved and non-ASCII” option add?

It also escapes every character above ASCII as a numeric reference, which helps when the output has to survive a system that mangles UTF-8.

Why did   come back as an ordinary-looking space?

It decodes to U+00A0, a real non-breaking space character. It looks like a space but is a different code point — the Unicode Converter will show it.

Does it handle entities I have not seen before?

Decoding does, because it defers to the browser's parser. Encoding deliberately uses a small, predictable set.

Related tools

• URL Encoder — Percent-encode components or whole URLs
• Unicode Converter — Escape, unescape and inspect code points
• HTML Formatter — Indent and tidy HTML markup
• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries

More Encoders & Decoders tools

• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries
• URL Encoder — Percent-encode components or whole URLs
• JWT — Read, verify and sign JSON Web Tokens
• Punycode — Convert internationalised domain names to and from their ASCII form
• Unicode Converter — Escape, unescape and inspect code points
• Unicode Inspector — Analyse every character: category, script, block and encoding
• Number Base Converter — Binary, octal, decimal and hexadecimal, with the bits explained
• Hex and Text Converter — Text to hexadecimal bytes and back, with a dump
• Gzip Compressor and Decompressor — Compress and expand gzip, zlib and raw deflate