HTML Entity Converter

Escaping is the front line against XSS

Cross-site scripting has sat near the top of the web's vulnerability rankings for two decades, and at its root it is an escaping failure. The pattern never varies: an application takes text from a user, inserts it into a page without escaping, and the browser — which cannot distinguish content the author wrote from content an attacker submitted — parses the attacker's angle brackets as real markup and runs their script. From there the attacker can read cookies, hijack sessions, rewrite the page and exfiltrate data, all under your domain's authority. The defence is deceptively simple: escape user input when you render it. Modern frameworks do this by default precisely because getting it wrong is so common and so damaging, and the dangerous constructs are the ones that explicitly opt out of it.

Escape at output, not at input

A subtle but important point about where escaping belongs. It is tempting to escape data as it arrives and store the escaped version, which feels safe. It is not: you now have a database full of & entities that are wrong in every context that is not HTML — your emails, your CSV exports, your JSON API and your search index all contain garbage. Worse, someone will inevitably escape it again on the way out, producing the double-escaping soup. The correct discipline is to store data exactly as the user typed it, and escape at the moment of rendering, using the escaping appropriate to the destination — HTML entities for a web page, backslashes for a JSON string, percent-encoding for a URL. The escaping depends on where the data is going, which is why it belongs at the output boundary.