HTML Entity Encoder / Decoder

Minimal is right for almost every HTML context — UTF-8 pages render é, 한, 中 etc. directly, so only the five characters that confuse the HTML parser need to be escaped. Use 'all non-ASCII' when the destination must stay in pure ASCII (e.g., legacy email templates).

Named entities (©) are easier to read, decimal (©) and hex (©) work for any code point even if no name exists. All three decode the same.

Yes. The decoder accepts named, decimal, and hex forms in a single pass.

Yes — encoding uses code points, so characters outside the BMP (😀, 𝕏, etc.) encode and decode correctly.

No — encoding is not idempotent, because the ampersand it produces is itself in scope. 'a & b' becomes 'a & b' on the first pass and 'a & b' on the second, which renders as the literal text & on the page. Decoding is the opposite: it is stable, so running it again on already-plain text changes nothing. If you are unsure whether a string was already encoded, decode it first and then encode once.

All of them. Decoding goes through the browser's own HTML parser, which knows every named reference HTML5 defines (over two thousand), so ≂̸ decodes just like …. The encoder is narrower: it writes names for about thirty common characters — the five markup characters plus currency, punctuation and typographic marks like …, — and ’ — and a numeric reference for anything else. Numeric forms always decode too: ≠ and ≠ both work. For encoding, prefer ' over ' for an apostrophe — ' is valid in XML and HTML5 but was never part of HTML 4, so the numeric form is the one that works everywhere.