Javascript has three similar properties for accessing an HTML element’s content: innerText, innerHTML, and textContent. In an effort to become a more informed Javascript programmer, I investigated the differences between these tools. Here’s what I learned:
Running Tests
After reviewing the MDN documentation for innerText, innerHTML, and textContent, I went back to one of my old Flatiron School labs to practice using each of them. This lab featured a handy paragraph with lots of inline elements. Here’s the HTML:
<p id=’test-node’> We’re writing <a href=”https://developer.mozilla.org/en-US/docs/Web/HTML">HTML</a> markup to display in our <strong>browser</strong>. We’re basically<br>telling computers what to do. <em>Neat!</em></p>
I ran three console.log commands in my Javascript file asking to see the innerText, innerHTML, and textContent of “test-node.” Here are the results:
innerText:
We’re writing HTML markup to display in our browser. We’re basically telling computers what to do. Neat!innerHTML:
We’re writing <a href=”https://developer.mozilla.org/en-US/docs/Web/HTML">HTML</a> markup to display in our <strong>browser</strong>. We’re basically telling computers what to do. <em>Neat!</em>
textContent:
We’re writing HTML markup to display in our browser. We’re basically telling computers what to do. Neat!
Okay so we’re telling computers what to do — but what does this tell us?
On a base level, innerText and textContent are going to wipe away our inline elements. They’ll share the bare text of what you are looking at (sort of a message without a medium). This might be especially useful if we were parsing text for a certain word or phrase. innerHTML on the other hand is going to re-print the HTML exactly, which is probably more useful for a lot of DOM manipulation situations. We’re seeing some use cases starting to evolve here.
One aspect of .innerHTML that isn’t illustrated in this example is that certain symbols, notably (<), (>), and (&) will be rendered as HTML entities by .innerHTML (“<”, “>”, and “&”, respectively).
innerText vs textContent
But why do both innerText and textContent exist if they return the same thing? Of course the answer is that they don’t return the same thing!
You may have noticed that the original HTML snippet was indented — so innerHTML reflected that formatting directly. textContent does the same thing: it reflects spacing and (manual) line breaks. Ironically, textContent won’t reflect line breaks created by inline elements like <br>, so if we were to drop one into our code like this:
We’re basically<br>telling computers what to do.innerText would show this:
We’re basicallytelling computers what to do.
And textContent would show this:
We’re basicallytelling computers what to do.One other note included in documentation is that innerText will display hidden text and styling where textContent will not.
Writing
My next tests were to manipulate the HTML using innerText, innerHTML, and textContent to see how each one communicates differently with the DOM. The results were about what you’d expect. Here’s my code:
testNode.innerText = `<p>here’s a p element</p><a href=”medium.com”>and here’s a link</a>`
And here’s the result (with innerText):
<p>here’s a p element</p><a href=”medium.com”>and here’s a link</a>
When I used innerHTML, it translated the inline elements:
here’s a p elementand here’s a link
And when I used textContent, it removed the line break:
<p>here’s a p element</p> <a href=”medium.com”>and here’s a link</a>Using these methods to conditionally populate elements in your DOM makes a lot of sense, but the MDN docs for innerHTML come with a warning:
Warning: If your project is one that will undergo any form of security review, using innerHTML most likely will result in your code being rejected. For example, if you use innerHTML in a browser extension and submit the extension to addons.mozilla.org, it will not pass the automated review process.
That’s because innerHTML renders complete markup rather than just text, which means utilizing it could leave a website vulnerable to a Cross Site Scripting (XSS) attack.
Again owing credit to MDN, Cross Site Scripting is defined as a security exploit which allows an attacker to inject into a website malicious client-side code. If we used innerHTML to render a user-inputted string onto our webpage (like if we allowed comments), someone could cleverly type a script that would change the intended behavior of our site. It could raise an alert, link to another page, or even capture sensitive information by accessing a cookie.
The good news is that HTML5 prevents the execution of a <script> tag inserted via innerHTML. So a <script>alert or <script deferred> won’t run. But there are ways around that, so it’s best to avoid allowing user submission via innerHTML where possible.
Conclusion
No surprise here: each of these three methods has its own place in your code, depending on your goals. My read is lean toward innerText and only use innerHTML to read properties or to set them if I’m really stuck on a problem. Ultimately, outside of the security concerns, the differences between these properties will likely be purely academic 99% of the time.