React sanitization libraries for safe user content

Why user content becomes risky in React

User content looks harmless until someone slips code into it. A comment, profile bio, support note, or forum post can carry more than text if your app lets it through.

Attackers do not need much. They can hide JavaScript in script tags, event handlers like onerror, or links that use javascript: instead of a normal URL. If that content reaches the page as real HTML, the browser may run it.

React helps, but only up to a point. When you render a plain string inside JSX, React escapes it for you. That means <script> shows up as text, not as code.

The risk changes when a team decides to render raw HTML. That often happens with dangerouslySetInnerHTML, WYSIWYG editors, imported CMS content, or a markdown pipeline that turns user text into HTML before React shows it. At that point, React no longer protects you by default. Your code now trusts the HTML.

Where problems usually start

Markdown feels safer because it starts as plain text. In practice, many markdown tools convert it into HTML first. If your pipeline allows raw HTML inside markdown, or if it fails to clean links and attributes, a simple docs page can become an attack path.

A small miss can spread far. Say your product shows user comments on blog posts, team notes in a dashboard, and markdown docs in a help center. If one shared render component accepts unsafe HTML, every page that uses it inherits the same risk.

That is why teams compare React sanitization libraries so closely. The issue is not only whether a library strips obvious script tags. It also needs to handle sneaky attributes, unsafe URLs, embedded content, and the exact HTML your app chooses to allow.

One bad render path is enough. If users can submit content in one place and other users can view it anywhere else, the problem stops being local very quickly.

What to compare before choosing a library

The first thing to compare is not the demo, the docs, or how fast you can install it. Compare how well the library blocks XSS. A package can feel easy on day one and still leave gaps once real user content starts coming in.

Some React sanitization libraries focus on cleaning raw HTML. Others fit markdown better, especially when you parse markdown into HTML before rendering it. If your app supports both, check the full path from input to output. The weak spot is often the step between markdown parsing and final render.

A useful comparison looks like this:

• What unsafe tags and attributes does it strip by default?
• Can you allow only the tags your product actually needs?
• Can you restrict risky attributes such as style, src, and iframe settings?
• Does it work in the browser, on the server, or both?
• Do the maintainers still fix bugs and add security tests?

Control matters more than many teams expect. A simple blog comment box may only need paragraphs, links, lists, and emphasis. Product docs may need tables, code blocks, and headings too. If the library makes custom allowlists hard to manage, your rules will drift, and people will start adding unsafe exceptions.

Support for your stack matters as well. If you render content in Next.js on the server and in the browser after hydration, you want the same behavior in both places. If one part of the stack sanitizes differently, you can end up with broken formatting or, worse, content that slips through one side.

Maintenance is the quiet filter that saves trouble later. Check release history, issue response, and test coverage around known XSS cases. Security work is rarely flashy, but stale packages age badly. For safe HTML rendering in React, the boring choice with clear rules and active maintenance usually wins.

How the main options differ

The biggest difference between React sanitization libraries is where they sit in your rendering flow. Some clean raw HTML. Some work best inside a markdown pipeline. Some give you tight control over what React components appear on the page.

DOMPurify is the simplest pick when you already have HTML and you want strong cleanup before render. Its default behavior is fairly strict, which is good news for user content. If a comment box, WYSIWYG editor, or imported HTML can contain unsafe tags or attributes, DOMPurify usually gives you a safe starting point with less setup.

sanitize-html takes a more explicit approach. You define which tags, attributes, and URL schemes you allow, then the library removes the rest. That makes it easier to match product rules. If you want to allow <b>, <i>, <a>, and nothing else, this style feels clear and predictable.

rehype-sanitize makes more sense when your content already goes through the unified ecosystem, such as markdown parsed with remark and rehype. In that setup, sanitizing at the pipeline level is cleaner than bolting a sanitizer on at the end. It also helps when you mix markdown with limited HTML.

react-markdown is a little different. It is not mainly a sanitizer. Its strength is control. You can decide how headings, links, code blocks, and lists render as React components. That is useful when you want consistent design and tighter rules around what markdown can do. Many teams pair it with sanitize rules or plugins instead of trusting raw HTML inside markdown.

A simple way to think about the options:

• DOMPurify: best when you need to clean HTML input fast and safely
• sanitize-html: best when you want a readable allowlist
• rehype-sanitize: best for markdown and HTML pipelines built on unified
• react-markdown: best when component-level control matters more than raw HTML support

One warning matters across all of them: raw dangerouslySetInnerHTML is fine only if you fully control the sanitize step first. If you skip that step, you leave the door open to XSS. For safe HTML rendering in React, the library matters, but the order matters just as much.

How to judge XSS protection in practice

A sanitizer earns trust when it survives ugly input, not when it cleans a friendly paragraph. When you compare React sanitization libraries, run the same hostile samples through each one and inspect the final HTML, not just the preview on screen.

Start with the easy cases. A good package should remove <script> tags, but that test alone proves very little. Many weak setups block scripts and still let risky inline handlers through, such as onclick, onerror, or onload. An <img src="x" onerror="alert(1)"> payload is a better test than a plain script tag because real attacks often hide in attributes.

Then check URLs. Sanitizers should reject javascript: links, and they should treat data: URLs with care. Some teams allow data:image for inline images, which can be fine, but broad data: support creates room for abuse. Also look at link attributes like target and rel. If user content can open a new tab, the output should stay strict and predictable.

A short test pack helps:

• <script>alert(1)</script>
• <a href="javascript:alert(1)">click</a>
• <img src="x" onerror="alert(1)">
• SVG input with event handlers or embedded links
• Broken or malformed HTML with missing quotes and half-closed tags

SVG deserves extra attention. Some libraries treat it like harmless markup, but SVG can carry scripts, events, and odd namespace behavior. Iframe support needs the same caution. If a package lets you keep iframes or custom attributes, the allowlist has to be very tight. If the docs stay vague on SVG, iframe rules, or URL handling, I would be careful.

Malformed input matters because attackers rarely send neat HTML. They use bad nesting, mixed case, stray quotes, and encoded characters to slip past weak filters. Test what happens when the input is messy, not just when it looks like a clean comment or markdown block.

One more thing trips teams up: using different rules on the server and in the browser. If server render strips one attribute but client render keeps it, you get inconsistent output and sometimes a security gap. Use the same policy in both places, especially for docs, comments, and any React markdown sanitization flow. Consistency is boring, but it blocks a lot of avoidable mistakes.

Which tools fit markdown best

If your app only needs basic markdown, keep the setup small. Headings, lists, emphasis, and links do not need many moving parts. In that case, react-markdown is often the cleanest choice because it renders markdown as React elements instead of pushing raw HTML into the page.

That choice also gives developers more control. You can map markdown nodes to your own components, so a link, image, or code block can follow your app's rules and design. For comments, help docs, or simple knowledge base pages, that is usually enough.

Raw HTML changes the risk level. If authors can type HTML inside markdown, parse first and sanitize after the markdown pipeline has turned that content into a structure you can inspect. Sanitizing too early is a weak habit because the final output may still include tags or attributes you did not expect.

If you already use remark and rehype, rehype-sanitize fits well. It lets you define an allowlist for tags, attributes, and URL schemes after markdown processing. That makes it a strong match for teams that want fine control and already work in the markdown AST pipeline.

A simple split works well in practice:

• For plain markdown with no raw HTML, use react-markdown and keep the rules tight.
• For markdown with GitHub-style extras like tables or task lists, add the plugins you need, but only those.
• For markdown that allows raw HTML, use a remark and rehype pipeline with rehype-sanitize.
• For tools that output one HTML string, DOMPurify or sanitize-html can clean it, but you give up some component-level control.

Decide early which markdown features you allow. Images, tables, task lists, and code blocks sound harmless, but each one adds rules you need to review. Images raise questions about allowed sources. Tables add more tags. Code blocks often need language classes. Task lists can introduce checkbox markup you may want to restrict.

A small example makes the tradeoff clear. A product team may allow short release notes with headings, lists, and fenced code blocks. react-markdown with a limited plugin set is a neat fit. A public forum where authors can paste HTML snippets needs stricter sanitation, and rehype-sanitize is the safer match.

How to choose a library step by step

Start with your content map, not the library list. Most teams have more input points than they think: comments, profile bios, support messages, admin notes, help docs, and imported content from old systems.

Treat each input type as a different case. Plain text needs escaping, markdown needs controlled parsing plus sanitization, and raw HTML needs the strictest rules. If you mix them into one pipeline, mistakes creep in fast.

A simple selection process works well:

1. Write down every place users can submit or edit content. Include public forms, internal tools, and any API that accepts rich text.
2. Mark each field as plain text, markdown, or raw HTML. Many apps can ban raw HTML completely, which cuts risk a lot.
3. Start with a tiny allowlist. Keep only the tags and attributes you actually need, such as p, strong, em, a[href], code, and maybe pre.
4. Build tests with realistic payloads. Check comments, links, images, code fences, pasted content from Word or Google Docs, and a few known XSS tricks.
5. Measure render cost before you commit. Long posts, large comment threads, and frequent updates can turn a safe setup into a slow one.

If your product only shows simple user posts, a smaller setup is usually better. For example, a markdown parser plus a sanitizer often gives more control than accepting raw HTML and trying to clean up everything later.

A practical rule

Pick the least powerful input format that still solves the problem. If users only need paragraphs, links, and code blocks, markdown is usually easier to defend than open HTML.

This is where React sanitization libraries differ in a way that matters. Some are easy to drop into a client app, while others give tighter control over allowed tags, attribute rules, and server-side handling. The right choice is the one your team can test, explain, and keep consistent across every place user content appears.

If two options look close, choose the one that makes unsafe input hard to ship by accident. That usually saves more time than a longer feature list.

A simple example with comments and docs

A SaaS product often has three very different kinds of user content: comments under tickets, release notes from the team, and help articles in a docs area. They do not need the same HTML rules, and treating them as if they do usually creates trouble.

Comments are the simplest case. Most apps should store them as plain text, keep line breaks, and maybe allow a very small slice of markdown such as emphasis or inline code. If you allow full HTML there, people can paste odd markup you did not plan for, and your cleanup work grows fast.

Help articles are different. Writers may need headings, lists, links, quotes, and code blocks. If your sanitizer strips all of that, the docs become hard to read. If it allows everything because docs need more structure, comments get the same wide opening for no good reason.

Split the rules by content type

One policy for every field sounds neat, but it makes both safety and editing worse. A better setup looks like this:

• Comments: escape HTML, allow plain text or limited markdown only
• Release notes: allow a small set of formatting tags and links
• Help articles: allow a broader set such as headings, lists, code, and tables only if you truly need them

That split keeps control where it belongs. It also makes safe HTML rendering in React much easier, because each renderer knows what kind of content it is expected to show.

Release notes sit in the middle. They usually need more structure than comments, but less freedom than full docs. Many teams forget that and either over-strip them or give them the same rules as articles.

This is where React sanitization libraries help, but the library is only part of the job. The bigger decision is your content model. If comments, release notes, and docs have different purposes, give each one its own parser and sanitizer settings instead of one global filter.

That choice cuts risk and saves time later. You spend less effort cleaning broken markup, and readers get content that looks right for the place where they see it.

Mistakes that create holes

Even good React sanitization libraries will not save you from policy mistakes. Most holes show up when teams trust content that only looks harmless, or when rules drift over time.

Markdown is the classic example. People see plain text with a few symbols and assume it is safer than HTML. It is not. Many markdown parsers accept raw HTML, loose image attributes, or unsafe URLs unless you disable those features or clean the output after parsing. A comment box that accepts markdown can still produce unsafe HTML if one plugin changes how links, images, or embedded content work.

Opening user links with target="_blank" can also cause trouble. If you allow that attribute, add strict rel values such as noopener noreferrer. Otherwise, the new tab can interact with the page that opened it. That sounds minor, but it gives untrusted content more reach than most teams expect.

Permission rules often get too broad. A team creates one wide allowlist for admins, then reuses it for moderators, imported docs, partner content, and public comments. That shortcut is risky. Internal staff notes and public user posts should not share the same rules. Split them early, even if the difference feels small.

Another mistake hides in product updates. Teams sanitize content when users save it, then later swap the markdown parser, add a plugin, or change how React renders certain tags. Old content stays in the database, but the new parser may read it in a new way. If you only sanitize on save, you miss that change. Render-time checks catch more problems.

A few checks prevent most of these gaps:

• Treat markdown as untrusted input
• Pair target="_blank" with strict rel rules
• Keep separate allowlists for each trust level
• Re-test stored content after parser or renderer changes
• Apply the same rules to custom React components

Custom components deserve extra suspicion. If your renderer maps user content into <VideoEmbed> or <Callout>, those components can bypass the same controls you apply to plain HTML. Validate every prop, restrict URLs, and assume attackers will test the edges before your users do.

Quick checks before you ship

A React app usually gets unsafe content through more places than teams expect. Comments, support tickets, markdown docs, imported CMS text, and old admin screens can all turn into a raw HTML path. Before release, trace each one and make sure it passes through one sanitize layer with one clear policy. If one screen uses DOMPurify and another quietly trusts stored HTML, your review is not done.

Tests matter more than a clean demo. A sanitizer can look fine with normal text and still fail on the input attackers actually use. Give your test suite ugly payloads, not polite ones.

• Try script tags, inline event handlers like onerror, and javascript: URLs.
• Test broken nesting, half-closed tags, pasted Word HTML, and mixed markdown plus HTML.
• Check both saved content and live preview, because those paths often differ.
• Verify what happens after re-editing sanitized content in a rich text editor.

Client and server rules should match. If the browser strips an iframe but the server stores it, people will see one thing in preview and another after refresh. That mismatch also makes bugs hard to track down. Pick one allowlist for tags, attributes, and URL schemes, then apply the same logic everywhere you sanitize or validate content.

Writers and editors need plain rules too. If your app accepts paragraphs, links, code blocks, and lists, say that clearly in the editor UI or docs. If it drops inline styles, custom classes, or raw HTML, say that too. People get frustrated when formatting disappears for no obvious reason, and frustrated users tend to search for workarounds.

Rejected content is useful, but logs can become their own risk. Log the reason a payload failed, the user or document ID, and a safe escaped sample if you need one for review. Do not dump raw hostile HTML into dashboards, admin tables, or error emails where someone might render it by accident.

This is where React sanitization libraries earn their keep. The best setup is boring: one policy, repeatable tests, matching behavior across server and client, and no hidden HTML shortcut waiting in an old component.

Next steps for your team

Stop treating all user content the same. A product comment, a support article, and a markdown doc need different rules. Write one policy for each content type: what tags you allow, which attributes stay, whether raw HTML is allowed at all, and who can post it.

Keep that policy in your repo, close to the code that enforces it. Once the rules are written down, the choice between React sanitization libraries gets much easier because you are judging tools against real output, not vague preferences.

If you plan to replace a sanitizer or add markdown plugins, write tests first. Use a small set of real samples: harmless formatting, pasted content from Google Docs, broken HTML, and obvious attack strings. Then add output tests so your team can see exactly what changed.

That step saves a lot of pain. Teams often swap a package for better XSS protection for user content, then learn too late that normal posts, tables, or code blocks no longer render the way writers expect.

A simple rollout usually looks like this:

• list every place where users can submit or view rich text
• define the allowed output for each place
• add tests for safe input, messy input, and hostile input
• swap one library or parser step at a time
• ask another engineer to review the rules

Bring in a short review when the rules start to spread across frontend rendering, backend storage, email templates, and admin tools. Small gaps show up there. Markdown may be sanitized in the app but not in exported docs, or one screen may allow attributes that another screen strips.

If your startup needs help with React content pipelines or a broader security review, Oleg at oleg.is can do a practical CTO-level audit. That works best when your team already has a draft policy and a few test cases, because the review stays concrete and you can fix issues right away.