Why HTML needs escaping at all
An HTML document is a stream of markup, and a few characters have structural meaning inside it. A less-than sign starts a tag, an ampersand starts a character reference, and a quote can end an attribute value. When one of those characters has to appear as text rather than as an instruction to the browser, it is written as an entity reference: either a named form such as < or a numeric form such as <. Both render as the same character.
Encoding is what you do when you paste a code sample into a tutorial, when you show a user the markup they typed into a rich-text box, or when you need to quote an attribute value that itself contains quotes. It is also the safe direction for text you do not control, since escaped text is displayed rather than interpreted.
The five characters that matter
In practice five characters cover almost every case. The ampersand becomes &. The less-than sign becomes <. The greater-than sign becomes >. The double quote becomes ", and the single quote becomes '. The order is not optional: the ampersand must be replaced first, otherwise the ampersands introduced by the other four replacements get encoded a second time and you end up with &lt; where you wanted <.
Why escape the quote characters at all? Because attributes are quoted, and a value like title="he said "stop"" ends the attribute early. Inside a double-quoted attribute an unescaped double quote breaks the markup outright. Single quotes matter when the attribute is single quoted, and the numeric form ' is used rather than ' because apos only exists from HTML5 onward, while the numeric reference works in every parser.
Encode once, and know what is not covered
Running the encoder twice is the most common mistake. The second pass turns & into &amp;, which the browser renders as a literal ampersand followed by the letters a, m and p, so the page shows & where you meant a single character. If stray entity text appears on a rendered page, suspect a double pass or an entity escaped inside a context that never decodes it, such as a textarea's value read back as raw markup.
This tool encodes the five reserved ASCII characters and nothing else. Accented letters, emoji and other non-ASCII text are left alone, which is correct for a UTF-8 page: they need no entities, and encoding them would only make the source harder to read. Encoding is also not a complete defence against script injection. It is the right treatment for text in HTML body and attribute contexts, but JavaScript strings, CSS and URL contexts each need their own escaping, so keep using your framework's contextual escaper for untrusted input. If the target is a URL rather than markup, the URL encoder and decoder handles percent-encoding instead, and the text to hex converter covers the case where you need the raw bytes.
An example: showing a link as code
You are writing a tutorial and want readers to see the markup for a link whose text contains an ampersand and an apostrophe: an anchor pointing at a search page, with the visible text Tom and Jerry's. Pasted raw into the article, the browser would treat the angle brackets as a real link and the ampersand as the start of a reference. Encoded, it arrives as <a href="/search">Tom & Jerry's</a>, which renders exactly as typed, angle brackets included, and never becomes a live link. The same output can be dropped into a CMS field that renders HTML literally without breaking the page.