Why HTML needs escaping
Five characters have structural meaning in HTML. < starts a tag, > ends one, & starts a character reference, and the two quote characters terminate attribute values. If any of them appears in text that came from a user, a database or an API and is written into a page unescaped, the browser will interpret it as markup. That is the entire mechanism behind cross-site scripting: a comment containing <script> becomes a running script rather than visible text.
Escaping replaces each of those characters with an entity - a name or number between & and ; - so the browser renders the character instead of acting on it. < displays as a less-than sign and can never open a tag. The rule of thumb is simple: escape at the moment of output, not on input, and escape for the context you are writing into. HTML text and HTML attributes need entity escaping; a URL needs percent-encoding; JavaScript string literals need backslash escaping. Mixing them up is how injection bugs survive review.
Named, decimal and hex references
There are three ways to write the same character. A named reference such as © is readable but only works for names the HTML standard defines - there are about 2,200 of them, and a typo like ©right; simply prints as literal text. A decimal reference uses the Unicode code point: ©. A hex reference uses the same number in hexadecimal: ©. All three produce an identical character in the rendered page, and the numeric forms work for every character in Unicode, including emoji, which have no names.
One name worth singling out is , a non-breaking space (U+00A0). It prevents a line break and does not collapse with neighbouring spaces, which makes it useful between a number and its unit - 10 kg - and a nuisance when it is pasted invisibly from a word processor into code, where it looks like a space but breaks parsers. The decoder here converts it back to a regular space character so you can see what you actually have. Another is ': it is valid in HTML5 and XML but not in HTML 4, so the numeric ' is the safer choice for an apostrophe inside an attribute.
When to encode non-ASCII characters
On a modern page declared as <meta charset="utf-8"> you do not need to encode accented letters, curly quotes, em dashes, currency symbols, Greek letters or emoji at all - write them literally and they will render correctly everywhere. Encoding them anyway makes the source larger and much harder to read.
The option is there for the cases where it genuinely helps: email templates that may be transcoded along the way, files that must remain pure 7-bit ASCII for a legacy pipeline, XML feeds with an uncertain declared encoding, or debugging a page where a character arrives as mojibake and you need to see its exact code point. Turning the option on writes every character above ASCII as a hex reference, which is safe under any encoding. Decoding always accepts all three forms regardless of the option. Everything runs locally in your browser - no request is made, so you can safely paste template fragments or customer content.