Two different defenses that people constantly mix up. One checks format. The other prevents injection.
| Input Validation | Output Encoding | |
|---|---|---|
| Purpose | Ensure data matches expected format | Make data safe for a specific output context |
| When it runs | On input — before processing | On output — before rendering |
| Example | Reject if email doesn't match pattern | Convert < to < before HTML |
| Prevents | Malformed data, some injection | XSS, injection in the output context |
| Context-aware? | No — validates against a generic rule | Yes — different encoding for HTML, JS, URL, CSS |
| Sufficient alone for XSS? | No | Yes (when applied correctly in every context) |
| Can be bypassed? | Often — via encoding tricks, edge cases | Rarely — if the right encoding is used |
Validation decides whether to accept input. Encoding decides how to safely emit it. They solve different problems, they happen at different moments, and substituting one for the other is the single most common cause of injection bugs that survive a security review — because the team believed the input was "sanitized" and stopped thinking about the output.
Validate on the way in, encode on the way out — and encode for the specific destination. Validation belongs at the boundary where data enters your system and should be about business rules: is this a plausible email address, is this quantity a positive integer, is this state code one of fifty. Encoding belongs at the moment data leaves your system into another interpreter, and the correct encoding depends entirely on which interpreter that is.
Why validation can't do encoding's job: the same value is legitimately dangerous in one context and harmless in another. O'Brien is a real surname, valid input by any reasonable rule, and it will break a concatenated SQL query. Stripping the apostrophe at the boundary corrupts the data for every other use — the customer's name is now wrong in their invoice, their email and their support ticket — to solve a problem that only exists in one place. Worse, it teaches the team that input is "clean", so the next developer concatenates without thinking.
Why encoding can't do validation's job: encoding has no opinion about meaning. HTML-encoding a quantity of -500 produces a perfectly safe string that still represents a negative order. Encoding protects the interpreter; validation protects your business logic.
The context list matters more than the technique. HTML body, HTML attribute, unquoted attribute, JavaScript string, URL parameter, CSS value — each needs a different escape, and a framework that handles one correctly will happily hand you a bug in another. Most surviving XSS is a context mismatch rather than an absence of encoding.
A user sets their display name to O'Brien <script>alert(1)</script>.
At input, validation asks a business question: is this under 80 characters, does it contain only characters we permit in a name? You may reasonably reject it on length or character class. What you should not do is silently strip the angle brackets, because now you've corrupted data to solve a rendering problem you haven't actually solved.
Into the database: use a parameterized query. The apostrophe is data, the driver sends it separately from the statement, and nothing needs escaping. Store the value exactly as the user typed it.
Into an HTML page: HTML-encode. The angle brackets become entities, the script tag renders as visible text, the apostrophe is fine.
Into a JavaScript variable: HTML encoding is the wrong tool and will produce broken output or a bug. You need JavaScript string escaping — or better, serialize to JSON and let the parser handle it.
Into a shell command or an LDAP query: different escaping again, or preferably an API that takes arguments as a list rather than a string.
One stored value, five correct behaviours, and the only one that would have been wrong for all of them is mangling it at the front door.
There's a third thing, often conflated with both: sanitization, meaning transforming input to remove dangerous content while keeping the rest. It's genuinely necessary in one case — when you must accept rich HTML from users, as in a comment system or a WYSIWYG editor — because you cannot simply encode it all without destroying the feature.
When you do need it, use a maintained library with an allowlist: DOMPurify on the client, a well-reviewed server-side sanitizer otherwise. Hand-written filters fail, reliably and repeatedly, because the attacker only needs one construct your regex didn't anticipate and browsers are extraordinarily forgiving parsers. Mutation XSS — where the sanitizer and the browser's parser disagree about what a string means, so markup that was safe when checked becomes executable when reparsed — is specifically the failure mode of homegrown sanitizers.
Prefer mechanisms that make the safe path the default: parameterized queries rather than escaping, template engines that auto-escape rather than manual encoding, and APIs that take argument lists rather than command strings. Validate with allowlists where the format permits it — a state code, a UUID, an enum — and with type and range checks otherwise. Treat blocklists of dangerous characters as a sign that the design is wrong. More at XSS and SQL Injection.
Generally no. It corrupts legitimate data — apostrophes in surnames, plus signs in email addresses — and it doesn't reliably prevent injection, because safety depends on the output context rather than the character. Store faithfully, encode at output.
Not at all — it's defense in depth and it enforces business rules that encoding cannot. It's just not a substitute for output encoding, and treating it as one is what leaves injection bugs in reviewed code.
Encoding makes data safe for a context while preserving it entirely — the script tag becomes visible text. Sanitization removes or rewrites content, losing information. Encode by default; sanitize only when you must accept rich markup.
Only if HTML is the only destination. HTML encoding inside a JavaScript string, a URL parameter or a CSS value is the wrong escape and can produce a bug rather than prevent one. The encoding has to match the interpreter.
Because auto-escaping covers the default HTML context and applications frequently leave it — raw-HTML escape hatches like dangerouslySetInnerHTML, values injected into inline script blocks, URL attributes accepting javascript:, and client-side DOM manipulation the server never sees.