What Are HTML Entities and When Do You Need to Encode Them?
HTML entities are escape sequences that let you put a character into a page when the raw character would mean something else. The HTML Entity Encoder and Decoder converts in both directions.
The four that matter
The less-than sign starts a tag, so a raw one in your text makes the browser look for a tag name. The greater-than sign closes one. The ampersand starts an entity, so a raw ampersand followed by letters and a semicolon can be read as a different character entirely. And the double quote ends an attribute value, which is how a quote inside an attribute breaks out of it.
Everything else - accented letters, symbols, emoji - works as a literal character on any modern page, because pages are served as UTF-8. The old habit of encoding every accent belongs to a time when the character set could not be relied on.
What goes wrong without it
The harmless failure is a page that renders oddly: text disappears because the browser thought it was inside a tag, or an ampersand swallows the words after it.
The serious failure is cross-site scripting. If a page displays something a user typed and does not encode it, a visitor can type a script tag and have it run for everyone who views the page. That is not an edge case; it is one of the most exploited classes of web vulnerability, and encoding on output is the fix.
Encode on output, not on input
This is the part that is commonly got backwards. Store what the user actually typed, and encode it at the moment you put it into a page.
Encoding on the way in corrupts your data. The text is now HTML-escaped in the database, so it is wrong when you send it in an email, export it to CSV with the JSON to CSV Converter, or display it anywhere that is not HTML. Worse, a later display layer may encode it again and your users see the escape sequences on screen.
The same text needs different escaping depending on where it is going - HTML, a URL via the URL Encoder and Decoder, or JSON. One encoding applied early cannot serve all three.
Common questions
Do I still need to encode accented characters?
No, provided the page declares UTF-8. Write them directly.
What about the non-breaking space?
That one is a deliberate choice rather than a safety measure - it prevents a line break between two words. Use it sparingly; a run of them is usually a layout problem in disguise.
Does encoding stop all script injection?
It stops the commonest form. Inserting user text into a script block or an event handler needs different escaping, and building HTML by string concatenation remains the underlying risk.
Why do I see ampersand-amp-semicolon on a live page?
Double encoding - something encoded the text twice, usually once on input and once on output. Encode in one place only.
Need to escape some text safely?