HTML Entity Encode / Decode

Small tool, but it exists because of a genuinely serious problem: if you render user-supplied text into a page without encoding it, you've opened the door to XSS. This encodes the handful of characters that matter and decodes entities back to plain text when you need to read them.

Only five characters actually matter

For security purposes, this comes down to five characters: & (ampersand), < (less than), > (greater than), and the two quote characters used inside attributes. Everything else can go through as raw UTF-8 on a modern page — you don't need to entity-encode em dashes or emoji, and doing so just makes the source harder to read for no security benefit.

Why this is the actual defence against XSS

If a comment field, a search box, or any other user input gets dropped straight into HTML output, an attacker who types <script>...</script> gets their JavaScript executed in every other visitor's browser who views that content. Encoding those five characters before the text ever touches the page turns that payload into inert text that renders as a literal string instead of a tag. This is exactly the kind of thing that's easy to get right in one place and then forget in the one place that matters — search result highlighting, error messages that echo back user input, and anywhere else raw strings get concatenated into HTML are the classic places this slips through.

One caveat

Encoding protects you when text ends up inside HTML content or attribute values. It does not automatically make a string safe to drop into a <script> block, a URL, or an inline event handler — those contexts have their own escaping rules, and mixing them up is exactly how people end up with an XSS bug despite technically "encoding everything."