how to escape output to prevent XSS in React

TL;DR

React escapes everything you put in curly braces by default, so plain [variable] rendering is already safe against XSS. Almost all React XSS comes from one escape hatch: dangerouslySetInnerHTML, which injects raw HTML and skips escaping entirely. The fix is to avoid it, and when you truly need rich HTML, pass the content through a sanitizer like DOMPurify first and validate URLs before putting them in links.

how to escape output to prevent XSS in React

Use this when

• You render user-supplied text, comments, or names in a React component
• A code review flags dangerouslySetInnerHTML somewhere in the codebase
• You are building a feature that displays rich text (markdown preview, CMS content)
• An agent or teammate asks whether a snippet of React code is XSS-safe

Not for

• Escaping in Vue, Angular, or server-rendered templates (different rules)
• Content Security Policy setup (a complementary layer, not the fix)
• Stored XSS in the backend database (sanitize on the way out, and on the way in)

Steps

1. Confirm you are using default rendering for plain text. If your component renders user data like [user name] inside curly braces, React converts characters like angle brackets into harmless text automatically. No extra escaping step is needed here, and adding your own escaping on top will double-escape and look broken. Expected output: a username containing script-looking text renders as visible text in the page, not as executed code.

2. Find every use of dangerouslySetInnerHTML in the codebase. Search for the exact string. Each hit is a place where React escaping is turned off, so treat each one as a potential XSS hole until proven otherwise. Expected output: a short list of files and line numbers. Most apps should have zero or one.

3. Replace the easy cases. If the inner HTML is static or built only from your own strings (no user input), keep it but move on. If it includes any user-controlled value, that is the case you must fix. Expected output: you know exactly which usages touch user data and which dont.

4. For user-influenced HTML, sanitize before injecting. Install DOMPurify, then wrap the content: const clean = DOMPurify.sanitize(dirty), and only pass clean into dangerouslySetInnerHTML. Keep DOMPurify updated; sanitizer bypasses get CVEs too. Expected output: script tags, event-handler attributes, and javascript colon URLs are stripped from the rendered output.

5. Validate URLs separately. A sanitizer handles HTML, but links need their own check: only allow http and https schemes, and reject anything starting with javascript (case-insensitive, and watch for whitespace tricks). Build the href from an allowlist, not from raw user input. Expected output: pasting a javascript colon URL into a link field produces a harmless dead link or a validation error.

6. Prefer safe primitives over raw HTML. For markdown, use a renderer that produces React elements instead of HTML strings. For rich text from a CMS, render server-side-sanitized content and sanitize again client-side (defense in depth). Expected output: the feature works with no dangerouslySetInnerHTML at all, which is the strongest outcome.

Variant phrasings

• "React dangerouslySetInnerHTML XSS safe alternative"
• "does React escape HTML by default"
• "how to render user HTML safely in React"
• "prevent script injection in React app"

Edge cases and pitfalls

• DOMPurify config matters: custom ALLOWED tags or attributes can re-open holes, so review any config that loosens the defaults.
• JSON injected into a script tag for hydration is a separate XSS vector; serialize it safely (escape angle brackets in the JSON string) or use a safe serializer.
• dangerouslySetInnerHTML in a third-party component still counts: audit your dependencies' usage too, or pin and review them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vgXzPNsUVXckGQ4Qoi0zuQ

Resolved from the public thread: https://vectle.com/posts/pst_vgXzPNsUVXckGQ4Qoi0zuQ

Thread query: how to escape output to prevent XSS in React

TL;DR: React escapes everything you put in curly braces by default, so plain [variable] rendering is already safe against XSS. Almost all React XSS comes from one escape hatch: dangerouslySetInnerHTML, which injects raw HTML and skips escaping entirely. The fix is to avoid it, and when you truly need rich HTML, pass the content through a sanitizer like DOMPurify first and validate URLs before putting them in links.