The DOM Tree
The DOM is the browser's live, in-memory representation of an HTML document — a tree of nodes that JavaScript can read and modify.
- Describe what the DOM is and how it differs from the HTML source file
- Identify the main node types — Element, Text, and Comment
- Navigate the top of the tree using document, document.documentElement, and document.body
- Explain why the DOM is the indispensable bridge between JavaScript and what users see
You know how to write HTML and how to style it with CSS. Now it is time for the third piece: JavaScript's ability to reach into a page and change it while the user is looking at it. The bridge that makes this possible is the DOM.
What the DOM actually is
When a browser downloads an HTML file it does not display the text literally. It hands the source to the HTML parser, which reads the tags and builds an in-memory tree of objects — one object per element, per piece of text, per comment. That tree is the Document Object Model.
The DOM is not the HTML file. It is a live data structure in memory. Once it exists, the original source file is no longer relevant to the running page — the browser only looks at the tree.
Two practical consequences follow from that:
- The parser corrects mistakes. If your HTML has unclosed tags or elements in the wrong place, the parser applies recovery rules before building the tree. What ends up in the DOM may differ from what you typed.
- JavaScript modifies the DOM, not the file. When you write
document.title = 'New title', the HTML file on disk does not change. The browser updates the object in the tree, and the page reflects the new value immediately.
Node types
Every item in the DOM tree is a node. Nodes come in several types, but three matter day-to-day:
| Type | What it represents | Example |
|---|---|---|
| Element node | An HTML tag and its subtree | <p>, <div>, <input> |
| Text node | Raw text content inside an element | "Hello world" |
| Comment node | HTML comments | <!-- TODO: fix this --> |
Element nodes are what you interact with almost exclusively. Text nodes are
there under the hood — <p>Hello</p> is actually a <p> element node whose
single child is a text node containing "Hello".
The top of the tree
The DOM has a fixed structure at its root that every browser page shares:
document
└── document.documentElement ← <html>
├── document.head ← <head>
└── document.body ← <body>documentis the entry point — a global object the browser creates before any of your scripts run. Everything hangs off it.document.documentElementis the<html>element.document.headis<head>.document.bodyis<body>— the ancestor of almost everything users see.
You rarely need to reference documentElement or head directly, but knowing
they exist explains why document.body is not the absolute top of the tree.
Source vs live view
Open any page, right-click, and choose "View Page Source." That shows the original HTML file the server sent. Now open DevTools and look at the Elements panel. That shows the current state of the DOM — which may look different from the source if JavaScript has already run and modified it.
The Elements panel in browser DevTools is your real-time window into the DOM. When you select a node there and delete it, the page updates instantly — you are manipulating the DOM directly, not editing a file.
Why this matters
Without the DOM, JavaScript would have no way to interact with what a user sees. Every interactive feature on the web — a button that opens a menu, text that updates without a page reload, form validation that highlights a field red — works by reading or writing to the DOM tree.
Understanding that the DOM is a live, structured object (not a string of HTML markup) is the mental model that makes everything else in this module click.
Layout-related DOM reads can be expensive. The browser may need to flush pending style recalculations before it can answer a question like "how wide is this element right now?" — a problem called layout thrashing when reads and writes are interleaved in a loop. You will not hit this in small projects, but keep it in mind as pages grow.
Where to go next
Now that you have a mental picture of the tree, the next step is learning how to find specific nodes in it — that is what Selecting Elements covers.
Lab — Improve Core Web Vitals
Use Lighthouse and DevTools to identify Core Web Vitals failures on a sample page, then apply targeted fixes to bring all three metrics into the Good range.
Selecting Elements
querySelector and querySelectorAll let you find elements using the same CSS selector syntax you already know — they return live or static node collections.