Concept and context
Escaping and sanitization are different defenses: escaping represents data so it is not interpreted as syntax in an output context, while sanitization parses structured content and removes or transforms disallowed constructs.
Treating them as interchangeable produces incomplete filters.
A sound mental model separates the abstract concept from its concrete representation and from the environment in which it is used. That separation prevents assumptions that are valid for one protocol, library or format from being carried into systems whose rules or guarantees are different.
Fundamentals and terminology
Correct escaping depends on context because HTML text, attributes, URLs, CSS and JavaScript have different grammars.
A representation that is safe in element text is not automatically safe inside an event attribute or JavaScript string.
Terminology should be read together with the standard, version or contract that defines it, because similar words can describe different properties at different layers. Making those definitions explicit improves interoperability, documentation and the ability to diagnose unexpected behavior.
How it works
Modern template engines often auto-escape interpolated text, but raw-HTML APIs can bypass that protection.
An HTML sanitizer must understand markup structure, apply an allowlist and handle dangerous attributes, URL schemes and nested constructs.
In real systems it helps to follow data across layers and identify which transformations are reversible, which introduce constraints and where information can be lost. This makes responsibilities among producers, consumers, storage and transport easier to reason about and test.
Worked example
Displaying <b>Hello</b> literally only requires escaping HTML delimiters; intentionally allowing some markup requires structured sanitization.
A policy might keep b and em while removing script elements, event handlers and javascript: URLs.
A worked example becomes reusable when it exposes its preconditions and invariants rather than showing only an end result. Changing one assumption at a time helps distinguish behavior guaranteed by a standard from choices made by a particular application or implementation.
Errors and misconceptions
Replacing only < and > does not cover every output context, and generic regular expressions are not reliable HTML parsers.
Multiple decoding steps, DOM mutation and string concatenation across contexts can reactivate content after an earlier filter.
Many failures come from implicit assumptions between systems that look compatible while using different versions, canonicalization rules or type models. For interoperability and security, unusual inputs should therefore be specified and tested deliberately instead of being treated as irrelevant edge cases.
Best practices and selection criteria
Keep untrusted data as text whenever possible, rely on contextual auto-escaping and use mature sanitizers only when accepting HTML is a product requirement.
Add Content Security Policy as defense in depth, not as a replacement for correct encoding and validation.
Robust practice combines documented standards, mature libraries, explicit contracts and tests that include representative boundary cases. The best choice is not automatically the shortest or most popular one; portability, readability, performance, security, evolution and operating cost all matter.
