What the DOM actually is
The tree the browser builds from your HTML — nodes, elements, and the model your code is poking at.
You wrote some HTML. The browser opened it. Now your JavaScript wants to change a heading, hide a button, or react when someone clicks. Before any of that makes sense, you need a clear picture of what your code is actually talking to. It is not the HTML file on disk. It is not the pixels on the screen. It is something in the middle, called the DOM (Document Object Model) — a live tree of objects the browser built from your HTML.
This first lesson is just about that picture. No code that changes the page yet. Just: when you write document.querySelector('h1'), what is document, and what comes back.
From text to tree
Your HTML file is a string of characters. The browser reads that string, top to bottom, and builds a tree-shaped data structure out of it. Each opening tag becomes a parent. Each tag nested inside becomes a child. Plain text between tags becomes a child too — a special kind, but a child.
A tiny page:
<!doctype html> <html> <body> <h1>Hello</h1> <p>I'm a <em>page</em>.</p> </body> </html>
The browser turns that string into something like this in memory:
A useful picture: the DOM is a family tree the browser drew while reading your HTML. The <html> tag is the great-grandparent at the top. <body> is its child. Each tag inside <body> is a grandchild, and so on. Your JavaScript can ask: "who is this element's parent?", "who are its children?", "what is its first sibling on the right?". The tree is the whole vocabulary.
The root of that tree is the global object called document. When you type document in the console, you are looking at the very top of the picture — the entry point your code uses to reach everything else.
The DOM is not stored as text. It is stored as objects. document has properties like body and head; document.body has a children property that is itself a list of objects. You navigate it with dots, not by parsing strings.
Nodes vs elements
You will hear two words used almost interchangeably: node and element. They are not the same, and the difference matters once you start touching the tree.
- A node is anything in the tree. Tags, text, comments — every box and every label hanging off the tree is a node.
- An element is a node that came from a tag.
<h1>,<p>,<em>— those are elements.
So every element is a node, but not every node is an element. The text "Hello" inside that <h1> is a node too — a text node — but it is not an element. Comments (<!-- … -->) are nodes but not elements either.
Most of the time, your code wants elements. The shortcut for that is to ask for children, not childNodes:
const body = document.body; console.log(body.childNodes); // includes whitespace text nodes console.log(body.children); // only the elements: <h1>, <p>
childNodes gives you the raw list — every node, including the whitespace between your tags (yes, that whitespace becomes a text node). children filters that down to elements only. For day-to-day work, children is what you want.
document.body.childNodes.length on the example HTML above and get a number larger than 2. Why?The DOM is live
The tree is not a snapshot. It is the current state of the page. Change a property on a node, and the page updates immediately — no rebuild, no refresh, no opt-in. Add a new element, and it shows up. Remove a node, and the user sees it disappear.
const heading = document.querySelector('h1');
heading.textContent = 'Goodbye';
// the page now reads "Goodbye"That last line is the whole game. You held a reference to a tree node, you changed one property on it, and the rendered page reflected the change. The same is true going the other way: the browser will also update the tree when the user types into a form, drags a slider, or any other interaction. The DOM is the shared, live model — your code and the user are both pushing changes into the same tree.
A useful analogy: a whiteboard you and the user are both drawing on. You can erase a word, the user can write one, the room sees both. The DOM is that whiteboard, and document is the marker.
The analogy stops there because the DOM has structure — it is not a flat surface. But the liveness is the part to keep.
document.body.style.background = 'lightyellow' in the console. Nothing else happens after the assignment. What do you see on the page?Not the same as your HTML file
This is the part that trips people up the first time. The DOM is built from your HTML, but it is not the same as it. Two things can make the live tree drift away from the original file:
- The browser fixes broken markup. If you forgot a closing tag or nested elements illegally (like a
<div>inside a<p>), the parser repairs the tree silently. The DOM you inspect in devtools is the fixed version, not the raw source you wrote. - JavaScript can change anything, any time. The moment your script runs, it might add elements, change text, or remove whole sections. After that runs, the DOM no longer matches the HTML you saved.
<p>One <p>Two</p>
That looks like a <p> containing another <p>. But <p> cannot contain <p>, so the browser auto-closes the first one. The DOM you see in devtools is two sibling paragraphs, not one nested in the other. View source shows your text. Inspect element shows the tree.
"View page source" shows the original HTML the server sent. "Inspect element" shows the live DOM right now. They start out matching, then drift the moment any JavaScript runs. When you debug a missing element, check the DOM — not the source.
The rest of this course is about touching that live tree on purpose: finding nodes, changing them, listening for the events the browser fires, and not breaking accessibility or security on the way. You now have the picture. Next lesson: how to find a specific node when the tree has thousands of them.