Sanitize HTML in JavaScript while preserving the formatting you allow

Consider an original internal notice that permits paragraphs, emphasis, and lists. An author pastes a repair instruction from an outside source. The application needs to retain the instruction's readable structure while preventing pasted markup from becoming executable page behavior.

Define the notice's permitted markup

In browser application code where a current maintained DOMPurify package is installed, sanitize the string immediately before the HTML insertion boundary:

import DOMPurify from 'dompurify';

function renderRepairNotice(target, untrustedHtml) {
  const clean = DOMPurify.sanitize(untrustedHtml, {
    ALLOWED_TAGS: ['p', 'strong', 'em', 'ul', 'ol', 'li', 'br'],
    ALLOWED_ATTR: [],
    ALLOW_DATA_ATTR: false,
    ALLOW_ARIA_ATTR: false
  });

  target.innerHTML = clean;
}

Here target is the application's intended HTML reading container. The policy deliberately omits links, images, classes, and inline styling because this notice does not need them. That restriction is an example application policy; other rich documents need a different supported set.

Do not silently broaden the list to make a pasted layout match. Identify the feature the author actually needs, then review the sanitizer policy and reader behavior for that feature. DOMPurify documents USE_PROFILES as an alternative way to select supported content families and notes that it overrides ALLOWED_TAGS; avoid combining those settings as though both lists independently apply.

Keep the cleaned result on its checked path

Suppose the incoming fixture contains:

<p>Disconnect the <strong>test lead</strong>.</p>
<img src="missing-image" onerror="alert('unexpected')">

Under the notice policy above, the instruction and strong emphasis should remain, while the disallowed image is removed. Inspect the returned string as literal text in a development panel, then inspect the resulting reading container. The expected behavior is a useful instruction with no image element or event-handler attribute retained from that image.

This is a small acceptance fixture, not a complete security test suite. Keep a maintained sanitizer and test the actual policy with the application's permitted content and known regression cases. Removing only <script> tags or event-handler names with a regular expression does not provide an equivalent HTML parsing and sanitization boundary.

DOMPurify warns that modifying sanitized markup afterward can undo its protection. Avoid concatenating unchecked HTML onto clean, passing it through a transformation that reintroduces unsafe markup, or moving the result into another parsing context without the appropriate protection for that context.

Use text handling for values that are text

The equipment reference beside the notice is a plain string. It can contain angle brackets without needing HTML interpretation:

referenceLabel.textContent = suppliedReference;

Use a dedicated element for that value. Encoding for an HTML text context, sanitizing an HTML fragment, validating a URL, and handling a JavaScript value solve different input-boundary problems. A cleaned fragment is not automatically safe to splice into a script, an arbitrary attribute, or a CSS value. OWASP describes why the output context determines the required protection.

The innerHTML guide explains how an HTML assignment parses a string and replaces child nodes. Sanitization adds the missing decision about which markup an untrusted author may contribute.

Apply the policy to stored and server-rendered notices

A browser-side sanitizer protects that particular rendering operation. It does not make the incoming request trusted, enforce who may edit the notice, or guarantee that another client renders the same stored record safely. Define the server's validation and sanitization policy and apply the relevant protection wherever saved content reaches a reader.

If you use DOMPurify in Node.js, its documentation requires a DOM implementation and recommends keeping that dependency current too. Browser initialization code cannot simply be pasted into a server runtime that has no document. Follow the documented server setup for the actual runtime and maintain both dependencies.

Keep any retained raw import separate from ordinary reader output and restrict its use. If the policy changes, decide how stored notices will be reprocessed or safely rendered under the new rule. A “sanitized” flag saved years earlier does not describe the current library, policy, and output path.

Check the rendered notice through its actual container

In development, verify allowed emphasis and lists, rejected elements and attributes, empty input, and a later reopened record. Inspect what the reader receives after all application transformations. If the page enforces Trusted Types, use DOMPurify's documented integration for that policy instead of weakening the site's Content Security Policy to accept a string assignment.

Keep client and server sanitization failures visible to the application; do not fall back to inserting the original string. For this notice, finish by reading the preserved test-lead instruction and inspecting the final DOM. The useful result is the authorized repair text with the intended formatting, delivered through the same protected path the next reader will use.