What HTML escaping is and why it matters
In HTML, certain characters carry structural meaning: < opens a tag, > closes it, & starts an entity, quotes delimit attribute values. If you want a literal less-than sign on the page without the browser thinking you're opening a tag, you escape it as <. The rule applies to any content placed between tags or inside attributes.
The five main characters
<escapes to<>escapes to>&escapes to&"escapes to"'escapes to'
XSS: the attack escaping prevents
Cross-Site Scripting (XSS) happens when an attacker injects JavaScript into a page other users will see. Classic vector: a blog comment. If the system renders <script>stealCookies()</script> without escaping, that script runs in every visitor's browser with access to the session and cookies. Escaping every user input before inserting it into the DOM kills the vector. Modern frameworks (React, Vue, Astro) escape by default, but if you inject content via innerHTML or dangerouslySetInnerHTML, the responsibility shifts back to you.
When to escape and when not to
- Always escape when inserting user input into the DOM, when rendering content from an API you don't control, or when logging data on a page.
- Don't double-escape. If a framework already escapes, doing it manually turns
&into&amp;and the user sees garbage. - Don't escape trusted, deliberate content. If you're inserting HTML you generated yourself and want it to render, escaping breaks it.
Showing code in a blog post
If your post teaches the <script> tag, you can't write it literally in the article HTML: the browser would interpret it as a real tag and try to execute whatever's inside. You escape the angle brackets to <script> and the reader sees the text. Many blog editors (WordPress, Ghost) escape automatically inside code blocks, but not always — keeping a manual escape tool around is handy.
Unescape: the reverse path
Sometimes you receive text that already comes with HTML entities (from an RSS feed, a JSON API that delivered HTML-encoded content, a database export). To display or process it as plain text, you unescape. If you're going to render it in the DOM afterwards, watch out: unescape and then inject via innerHTML is exactly what escaping prevents.
HTML vs URL encoding
Two different things. URL encoding turns unsafe characters into %XX (a space becomes %20). HTML escaping turns special characters into entities (a space stays the same, < becomes <). Mix them up and you end up with strings like %26lt%3B that mean nothing in any context.