How Browsers Turn HTML and CSS Into Pixels

The short answer

After receiving HTML, a browser parses it into a live document. It obtains and parses applicable CSS, works out which content needs to be displayed and how it should look, calculates geometry, and draws the result. It may combine separately drawn layers into the final image. Scripts and later resources can change that result.

This is a learning model, not a claim that every engine runs one neat pass. Parsing, fetching, styling, and drawing can overlap or repeat. The earlier URL journey gets the response to the browser; this lesson begins with what the browser does with it.

Mental model

Separate structure, style, geometry, and drawing. HTML helps form the DOM. CSS supplies style rules. The browser resolves applicable styles, lays out boxes, paints visual details, and composites the result. When something looks wrong, ask which of those responsibilities failed first.

System traceFrom response data to a displayed frameHTML and CSS can be processed while resources are still arriving. Their results inform style, layout, paint, and compositing; later changes may repeat only some stages.

HTML bytesParse into DOM nodes
CSS bytesParse style rules and build the CSSOM
Applicable stylesDetermine render information for visible content
LayoutCalculate size and position
PaintProduce drawing instructions and pixels
CompositingCombine layers where the engine uses them

What the browser receives

An HTML response is bytes with a declared or detected character encoding and a content type. The document can refer to separate CSS, JavaScript, images, fonts, and other resources. Those are additional fetches, not material magically contained in the first response.

This small page is illustrative, not a complete application:

Illustrative document with external resourceshtml

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Today’s notes</title>
  <link rel="stylesheet" href="/site.css">
  <script src="/app.js" defer></script>
</head>
<body>
  <main>
    <h1>Today’s notes</h1>
    <p>A short introduction.</p>
    <button type="button">Save</button>
    <img src="/chart.png" alt="A chart of the notes" width="400" height="240">
  </main>
</body>
</html>

The document gives the parser a heading, paragraph, button, and image element. /site.css can change their appearance. /app.js can add behavior when it runs. The image file supplies its pixels separately; its declared dimensions help the browser reserve space before it arrives.

Parsing HTML

The HTML parser turns characters into tokens and uses tree-construction rules to create nodes. It does not merely split the response at angle brackets: malformed or omitted markup can be repaired according to defined rules. The HTML parsing standard specifies this process.The standard defines parsing of text/html into DOM trees.¹

Parsing can begin before the entire response arrives. While reading the document, the browser can discover the stylesheet, script, and image and start fetching them. This helps explain why the Network panel may show multiple requests before the initial document has fully loaded.

Building the DOM

The Document Object Model, or DOM, is the browser's live object structure for the document. In the example, the heading element contains a text node; the main element contains several child elements. The DOM is neither the original HTML text nor the pixels on screen. Scripts may later add, remove, or modify its nodes.

The parser's output can differ from the literal source because parsing has rules and scripts can change the document. The next lesson examines the DOM as a programmable structure; here it is the structural input to rendering.

Parsing CSS and building the CSSOM

The browser parses CSS into rules it can apply to the document. The CSS Object Model, or CSSOM, describes style-related structures and APIs; in a rendering overview it is useful shorthand for the parsed style information the browser needs. It is not simply a verbatim copy of a CSS file in memory. The browser must account for selectors, the cascade, inheritance, media conditions, and user-agent styles when determining an element's effective style.MDN explains the CSSOM's role in the critical rendering path.³

A stylesheet relevant to the current display may delay the first styled render while it loads and is processed. That does not mean every CSS resource blocks every page in the same way: applicability and loading conditions matter.The HTML Standard defines when a stylesheet can be render-blocking and how a failed load is reported.²

Combining information for rendering

Browsers need both content and applicable style to decide what should appear. Many introductions call the resulting visible, styled representation a render tree. That term is a useful model, but browser engines do not promise one identical internal data structure or one universal pass.

For example, an element with display: none does not create a visible box in this model, while a visually hidden element can still occupy space depending on its styling. DOM membership alone does not tell you what will be drawn.MDN distinguishes DOM nodes from the visible render representation.⁴

Style calculation

For each relevant element, the browser determines the values that apply after the cascade, inheritance, and other CSS rules are considered. This is why a declaration in one file does not by itself prove the final color or size: a later rule, media condition, or inherited value may change the result.

When an element appears with an unexpected style, inspect its computed style and the rules that won the cascade before changing arbitrary CSS. Missing CSS and losing a cascade decision are different failures.

Layout

Layout determines geometry: the sizes and positions of boxes in the available space. Text wrapping, viewport width, fonts, image dimensions, and CSS layout rules can all affect those calculations. A narrow viewport can produce a different arrangement from a wide one even with the same DOM.

“Reflow” often means layout work done again after a change. If a font loads and changes text metrics, or a script changes a width, the browser may need to recompute affected geometry.MDN describes layout and later reflows.⁴ A layout problem is not necessarily a paint problem.

Paint

Paint turns the styled, positioned result into drawing work: text glyphs, colors, borders, images, shadows, and other visual details. A color change may require new paint without changing the position of surrounding boxes. Conversely, a width change may require layout and then paint.

This distinction is useful when reading a performance trace: two visual updates can look similar to a person while costing the browser different kinds of work.

Compositing

Browser engines may draw parts of a page into layers and combine those layers for a displayed frame. Compositing can sometimes update an existing layer without repeating layout or paint for its contents. Layer decisions, GPU work, and optimizations vary by engine and device; “every element gets a layer” is not a safe model.MDN describes compositing as a possible rendering stage.⁴

Where JavaScript enters the process

JavaScript may inspect or modify the DOM, change classes, fetch more data, or attach event listeners. A normal parser-encountered script can pause HTML parsing; defer, async, module scripts, and explicit blocking attributes have different scheduling behavior. The example's defer script is intended to run after parsing, not to block the parser at its position.

Not every script execution changes the DOM. Even a DOM change need not produce a visible difference. And “rendering” in React is not the same operation as browser rendering: React's render step computes component output, then its commit may update the DOM, after which the browser can perform visual work.React's own documentation separates render, DOM commit, and browser paint.⁶

External resources

The image may load after text first appears. A font can change text measurements when it becomes available. A script can add content after the first frame. A relevant stylesheet may delay an initial styled frame; a noncritical or inapplicable resource may not. The exact timing depends on how resources are declared and the browser's loading decisions.

Do not infer “the page is finished” from one document response with status 200. Check the resource requests and the displayed result separately.

What causes visual updates

Changing text, a class, an element's dimensions, an image, or the viewport can change the displayed frame. The browser attempts to redo the work that is needed, not mechanically restart every stage for every change. Some changes affect layout; others affect paint or compositing. There can also be style recalculation even when no pixels finally change.

Common misconception

Incorrect: Every DOM mutation forces the entire page through layout, paint, and compositing again.

Better model: A mutation may change nothing visible, or it may invalidate particular styles, boxes, or layers. The cost depends on the change and the engine's work. Measure the real path before optimizing it.

Rendering performance at a high level

Start by reducing unnecessary work: avoid large synchronous scripts on the main thread, give images dimensions when possible, and avoid repeatedly changing layout-affecting values during an animation. Do not assume that forcing more compositor layers is free; layers also consume resources. Performance tools can show whether time went to script, style, layout, paint, or compositing.web.dev separates these costs and recommends measuring rendering work.⁵

This lesson supplies vocabulary, not a universal optimization recipe. The later performance lesson will address bundles and metrics in context.

Common misconceptions

The DOM is the visible page

The DOM represents document structure and can include nodes that are not displayed. Pixels require styling, layout, and drawing work as well.

All resources must finish before anything appears

Browsers can parse and display useful content before some images or other noncritical resources finish. Relevant stylesheets and scripts can affect that timing, but resources are not interchangeable.

Debugging scenario

The document request returns 200, and the heading and paragraph appear in default-looking styles. The Network panel shows /site.css returning 404.

What worked? The browser obtained and parsed enough HTML to build the DOM and display text. Where did the expected presentation fail? The stylesheet resource was not found. Inspect the stylesheet URL, deployment output, and response before rewriting CSS selectors or blaming JavaScript. A different stylesheet or user-agent default styles may still affect what you see, so “unstyled” is a useful symptom, not a claim that no CSS applies.

Why this matters when working with AI-generated code

Generated code may respond to a styling problem by adding DOM nodes or JavaScript measurements when the real fault is a missing stylesheet. It may also animate layout-affecting properties without considering rendering cost. Ask which input and stage the change affects—document, style, geometry, or drawing—before accepting the patch. Framework re-render counts alone do not tell you what the browser painted.

Knowledge check

Reflect, then reveal each answer.

Is the DOM the same as the HTML response text?
No. The parser constructs a live node tree from HTML; scripts can then change it. Parsing rules can also make the tree differ from the literal source.
What does layout calculate?
Layout calculates the geometry of relevant boxes—their sizes and positions in the available space.
Can a page show text before an image finishes loading?
Yes. Parsing and rendering can proceed while noncritical resources are still arriving, subject to the resources and loading conditions involved.
Does every JavaScript function call require browser paint?
No. A script can run without a visible change, and a DOM update can sometimes leave pixels unchanged.
If HTML appears but a stylesheet returns 404, which boundary should you inspect?
The stylesheet request and resource path. HTML parsing succeeded; the expected CSS resource did not arrive.

What to learn next

How this connects

The DOM, Events, and User Interaction
Use the live document structure to understand how scripts find nodes and respond to actions.
CSS Layout and Responsive Interfaces
Later, study how style rules produce geometry across viewport sizes. This lesson is planned, not yet published.
Frontend rendering strategies
Later, separate browser rendering from server and framework rendering choices. This lesson is planned.

Key takeaway

When a page looks wrong, distinguish missing resources, document structure, style decisions, geometry, and drawing. Those are different failure boundaries.

Related concepts

References & further reading