Safe DOM Rendering Patterns in JavaScript

Every time JavaScript inserts dynamic content into the DOM, there is a choice: a safe API that treats the content as data, or a dangerous API that treats it as code. The difference is whether user input gets rendered as plain text or gets parsed as HTML.

The safe path is always to use APIs that never interpret strings as HTML. Picking the right API for the job means understanding which DOM methods parse strings and which treat them as inert text. This article covers the safe rendering patterns for every DOM insertion scenario, building on fundamental DOM selection and manipulation skills with security in mind.

The Golden Rule: Content vs Code

The decision tree is simple. If the string should be text, use textContent. If you need HTML structure, use createElement and build nodes. If you must render user-provided HTML, sanitize it first. Never let an unsanitized string cross the boundary from data to code.

Pattern 1: Rendering Text Content

The most common rendering task is inserting text. The safe way is textContent:

javascript

// Unsafe
document.getElementById("username").innerHTML = userProfile.name;
 
// Safe
document.getElementById("username").textContent = userProfile.name;

textContent treats the value as plain text regardless of what it contains. HTML tags, script blocks, and event handlers are displayed as literal characters. There is no way to inject HTML through textContent.

A worked example with a truly malicious input:

javascript

const maliciousName = `<img src=x onerror="alert('stolen: ' + document.cookie)">`;
 
// Using innerHTML: the script executes
el.innerHTML = maliciousName; // VULNERABLE
 
// Using textContent: the script is displayed as text
el.textContent = maliciousName; // Safe -- user sees the angle brackets

innerText is also safe and behaves similarly, but it triggers a layout recalculation. Prefer textContent for performance.

Pattern 2: Building HTML Structure Safely

When you need actual HTML elements, build them programmatically with createElement and setAttribute:

javascript

// Unsafe: building HTML with string concatenation
function renderCommentBad(comment) {
  return `
    <div class="comment">
      <strong>${comment.author}</strong>
      <p>${comment.body}</p>
    </div>
  `;
}
container.innerHTML += renderCommentBad(comment);
 
// Safe: building DOM nodes directly
function renderCommentSafe(comment) {
  const div = document.createElement("div");
  div.className = "comment";
 
  const strong = document.createElement("strong");
  strong.textContent = comment.author;
  div.appendChild(strong);
 
  const p = document.createElement("p");
  p.textContent = comment.body;
  div.appendChild(p);
 
  return div;
}
container.appendChild(renderCommentSafe(comment));

The safe version never concatenates user data into an HTML string. Every piece of user content is assigned through textContent on an element created by createElement. The browser handles all escaping internally.

Pattern 3: Setting Attributes Safely

Attributes have their own injection risks. The setAttribute method is safe for most attributes, but be careful with event handlers and URL-bearing attributes:

javascript

// Safe: plain attributes
element.setAttribute("data-id", userInput);        // Safe
element.setAttribute("class", userInput);           // Safe
element.setAttribute("title", userInput);           // Safe (text attribute)
 
// Unsafe: event handler attributes
element.setAttribute("onclick", userInput);         // VULNERABLE
 
// Unsafe: URL attributes with untrusted values
element.setAttribute("href", userInput);            // VULNERABLE (javascript: URL)
element.setAttribute("src", userInput);             // VULNERABLE (javascript: URL)

For event handlers, always use addEventListener:

javascript

// Safe
element.addEventListener("click", myHandler);
 
// Never do this
element.setAttribute("onclick", "myHandler()");

For URL attributes (href, src, action, formaction), validate that the value is a safe URL:

javascript

function safeSetHref(element, url) {
  // Only allow http:, https:, and relative URLs
  if (url.startsWith("http:") || url.startsWith("https:") || url.startsWith("/")) {
    element.href = url;
  } else {
    element.href = "#";
    console.warn("Blocked unsafe URL:", url);
  }
}

The javascript: URL scheme is executable. Never let untrusted input set an href or src without validation.

Pattern 4: Rendering Rich HTML with Sanitization

When you must render user-provided HTML, a text editor's content or an email body, use DOMPurify:

javascript

import DOMPurify from "dompurify";
 
function renderRichContent(htmlString) {
  const clean = DOMPurify.sanitize(htmlString, {
    ALLOWED_TAGS: ["b", "i", "em", "strong", "a", "p", "br", "ul", "ol", "li"],
    ALLOWED_ATTR: ["href", "target"]
  });
 
  document.getElementById("content").innerHTML = clean;
}

DOMPurify parses the HTML, walks every node, and removes anything dangerous: script tags, event handler attributes (onerror, onload, onclick), javascript: URLs, and HTML comments that could hide malicious code.

Configure the allowed tags and attributes to the minimum your application needs. If your users only need bold and italic, do not allow a tags or img tags.

Pattern 5: Rendering into Different Contexts

Different parts of the DOM need different escaping. A string safe for an HTML body might be dangerous in an attribute or inside a script tag:

javascript

// HTML body context: escape < > & " '
function escapeHtml(str) {
  return str.replace(/[&<>"']/g, char => ({
    "&": "&amp;", "<": "&lt;", ">": "&gt;",
    '"': "&quot;", "'": "&#x27;"
  })[char]);
}
 
// URL parameter context: encodeURIComponent
function buildUrl(base, params) {
  const qs = Object.entries(params)
    .map(([k, v]) => `${encodeURIComponent(k)}=${encodeURIComponent(v)}`)
    .join("&");
  return `${base}?${qs}`;
}
 
// CSS context: very limited safe usage
// Prefer setting individual style properties instead
element.style.color = userColor; // Validate the color value first

The table of escaping by context:

Never mix contexts. HTML escaping does not protect a value inside a URL. URL encoding does not protect a value inside HTML. Each context has its own rules.

Pattern 6: Content Security Policy as a Safety Net

Even with careful escaping, mistakes happen. A Content Security Policy is the final defense:

http

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'self';
  form-action 'self';

This policy means: even if an attacker injects <script>alert(1)</script> into the page through a missed escape, the browser does not execute it. CSP blocks inline scripts unless they have a matching nonce or hash.

For deeper coverage of CSP and injection prevention, see the XSS prevention guide.

Common Mistakes

Using innerHTML for simple text. The most common and most dangerous pattern. Every innerHTML = userString is a potential XSS. Use textContent.

Calling a sanitizer but then modifying the result. If you sanitize HTML, then do string operations on it, you can reintroduce vulnerabilities. Sanitize last, right before insertion.

Trusting sanitized output in attributes. DOMPurify cleans HTML elements and their attributes. But if you extract an href from sanitized HTML and set it with setAttribute("href", value), validate the URL separately.

Forgetting that JSON data can contain HTML. An API response like {"name": "<script>..."} is valid JSON. When you render that name into the DOM, escape it.