Why HTML has reserved characters at all
HTML uses < and > to mark the start and end of tags, and & to start an entity reference (like & itself). If literal text containing one of these characters were inserted directly into a page without escaping, a browser would try to interpret it as markup rather than displaying it as plain text — a literal "<" in the wrong place could be misread as the start of a tag that was never meant to exist.
The five characters this calculator handles
& becomes &, < becomes <, > becomes >, " becomes ", and ' becomes ' — these five cover the characters with dedicated meaning in HTML markup and attribute values. There's a much larger table of named entities for other symbols (like © for ©), but these five are the ones that matter for safely embedding arbitrary text without it being misinterpreted as markup.
A worked example
Encoding the literal text "<script>alert('hi')</script>" produces "<script>alert('hi')</script>" — every reserved character is escaped, so a browser displays the literal text of that string rather than treating it as an actual script tag to execute. Decoding it exactly reverses the process, recovering the original text.
Why decode order matters
When decoding, & must be processed last, not first — decoding & too early would turn an already-doubly-escaped sequence like "&lt;" into "<" instead of correctly recovering "<" as an intermediate step. Numeric entities (' and ' forms) are typically decoded before named entities for the same reason: getting the order right prevents one entity's decoding from corrupting another that hasn't been decoded yet.
Why this matters for security, not just display
Failing to HTML-encode user-supplied text before inserting it into a page is one of the most common causes of cross-site scripting (XSS) vulnerabilities — if a website takes text a user typed (like a comment or a search term) and inserts it into the page without escaping it, an attacker can submit text containing actual HTML/script tags that the browser will then execute as if the site itself had written them. HTML entity encoding untrusted text before display is a basic, essential defense against this class of attack, which is why it matters far beyond just "the text displays correctly."
Where this differs from URL encoding and Base64
HTML entity encoding is specific to text that will be placed inside HTML markup — it solves a different problem than URL encoding (making text safe to include in a URL) or Base64 (representing arbitrary binary data as text). Text destined for an HTML page, a URL, and a binary-safe text channel each need their own specific encoding, and applying the wrong one (or none) for the destination context is a common source of both display bugs and security vulnerabilities.