How does a browser turn my code into a page on the screen?

You write three kinds of text files — HTML, CSS, JavaScript — and somehow a browser turns them into an interactive picture. Understanding the broad strokes of how demystifies a surprising amount of everyday development.

Step 1: Fetching

When you enter a URL, the browser requests the HTML document from a server. As it reads the HTML, it discovers references to other resources — stylesheets, scripts, images — and requests those too. This is why a page is really a bundle of files, and why a missing file shows up as an unstyled page or a broken image rather than a total failure: browsers are built to keep going with whatever arrives.

Step 2: Parsing HTML into the DOM

The browser parses the HTML text into a tree of objects in memory: the Document Object Model, or DOM. Every element becomes a node in the tree, nested the way your tags nest. The parsing rules — including what happens when your HTML contains mistakes — are precisely defined in the WHATWG HTML Living Standard, which is why modern browsers handle even broken markup identically instead of guessing differently from one another.

The key insight for a learner: the page on screen is a rendering of the DOM, not of your HTML file. The file is just the starting recipe. Once scripts start modifying the DOM, the live tree and your source file diverge — which is exactly what you see when you use the browser's element inspector.

Step 3: Applying CSS

In parallel, the browser parses your stylesheets and works out, for every element in the DOM, the final value of every visual property — resolving conflicts between rules using the "cascade" that gives CSS its name. The practical details of selectors, specificity, and inheritance are laid out with examples in MDN's web documentation.

Step 4: Layout and paint

With structure and styles known, the browser computes geometry — how big each element is and where it sits — and then paints pixels. When something changes (a window resize, a class toggled by a script), the browser redoes as little of this work as it can get away with. This is the mental model behind the common advice that changing an element's geometry is more expensive than changing its color: geometry changes can force layout to be recalculated for much of the page.

Step 5: JavaScript joins in

Scripts run in this environment with the DOM as their interface to the page: they read it, modify it, and listen for events on it. A subtle consequence: a script that runs before the elements it references have been parsed will find nothing there. That single fact explains a whole family of classic beginner bugs, and it falls naturally out of the model above — the DOM is built in order, top to bottom.

Why this model is worth having

With it, the developer tools stop being mysterious: the element inspector shows the DOM, the styles panel shows the cascade's verdict, and the network panel shows step 1. You don't need implementation-level depth — but knowing the pipeline exists, and in what order it runs, turns "my page looks wrong" from a mystery into a question with a location. For the next layer down, MDN documents each stage's APIs, and the HTML standard remains the final word on parsing and element behavior.