How Browsers Work: An Overview

You type an address, hit Enter, and within a second a full page appears: text, images, buttons, colors, the lot. It feels instant and effortless. But behind that single moment, your browser runs through a surprisingly long chain of steps to turn a pile of text files into the picture on your screen.

This article gives you the big picture of that chain, end to end. We will not go deep into any single stage here. Instead, the goal is to name each part, explain what it does in plain language, and show how the pieces connect. Once you can see the whole pipeline, the deeper articles that follow will make a lot more sense.

What a browser actually is

It helps to start with what the word “browser” really means. A web browser is a program whose job is to fetch documents from the internet and display them to you. Chrome, Firefox, Safari, and Edge are all browsers. Under the hood they share the same broad design, even if the details differ.

A browser is not one single piece of software. It is a bundle of cooperating parts, each with its own responsibility:

• A networking component that downloads files over the internet.
• A rendering engine that turns those files into the visual page.
• A JavaScript engine that runs the code on the page.
• A user interface for the address bar, tabs, and buttons around the page.

The interesting work for our purposes happens in the rendering engine and the JavaScript engine. Everything below is really about how those turn raw files into pixels.

The journey, stage by stage

When you open a page, the work flows through a series of stages, roughly in order. Each stage takes the output of the one before it and transforms it a little further. Here is the whole pipeline in one diagram:

  You type a URL
        │
        ▼
  ┌──────────────┐
  │  NETWORKING  │  fetch HTML, CSS, JS, images over the internet
  └──────┬───────┘
         ▼
  ┌──────────────┐
  │   PARSING    │  HTML → DOM tree   |   CSS → CSSOM tree
  └──────┬───────┘
         ▼
  ┌──────────────┐
  │ RENDER TREE  │  combine DOM + CSSOM (only visible things)
  └──────┬───────┘
         ▼
  ┌──────────────┐
  │    LAYOUT    │  figure out size + position of every box
  └──────┬───────┘
         ▼
  ┌──────────────┐
  │    PAINT     │  fill in pixels: text, colors, borders, images
  └──────┬───────┘
         ▼
  ┌──────────────┐
  │  COMPOSITE   │  stack the layers together → final screen
  └──────────────┘

  (JavaScript engine runs alongside and can change any stage)

Let’s walk through each box.

Stage 1: Networking, fetching the raw materials

Before the browser can show anything, it needs the files that make up the page. That starts with the main HTML document, and HTML usually points to more files it depends on: stylesheets, scripts, images, fonts, and so on.

The networking stage handles all of this. The browser figures out which server holds the file, opens a connection, asks for the file, and downloads the response. This is where things like DNS lookups (turning a name such as blog.acy-partner.com into a numeric address) and the request and response exchange happen.

GET /index.html HTTP/1.1
Host: blog.acy-partner.com

The server replies with the HTML, and the browser starts reading it immediately, even before the whole file has arrived. As it reads, it discovers references to other files and kicks off more downloads in parallel. Networking is often the slowest part of the whole process, simply because it depends on the speed of the internet between you and the server.

Stage 2: Parsing, from text to structured trees

Once bytes start arriving, the browser has to make sense of them. Raw HTML and CSS are just streams of characters; the browser needs to convert them into organized data structures it can work with. This conversion is called parsing.

Two parses happen here, producing two trees.

HTML becomes the DOM

The browser reads the HTML and builds the DOM, short for Document Object Model. The DOM is a tree of objects, one for each element, nested the same way your tags are nested. A page like this:

<body>
  <h1>Welcome</h1>
  <p>Hello there</p>
</body>

becomes a tree where body is the parent, and h1 and p are its children. The DOM is the browser’s live model of the page’s structure and content. JavaScript later reads and changes the page by talking to this tree.

CSS becomes the CSSOM

In parallel, the browser parses every stylesheet into the CSSOM, the CSS Object Model. Like the DOM, it is a tree, but it describes style rules: which colors, fonts, sizes, and spacing apply to which elements. The CSSOM also works out which rule wins when several rules target the same element.

At the end of this stage, the browser knows what is on the page (DOM) and how it should look (CSSOM), but it has not combined them yet.

Stage 3: The render tree, deciding what is visible

Next the browser merges the DOM and CSSOM into a single structure called the render tree. This tree contains only the things that will actually be drawn, along with the styles each one should have.

Why a separate tree? Because not everything in the DOM appears on screen. Elements hidden with display: none, for example, are part of the DOM but contribute nothing visual, so they are left out of the render tree. The <head> of the document is in the DOM too, but you never see it, so it is skipped as well.

So the render tree is essentially the answer to one question: of everything in the document, what will the user actually see, and with what styling?

Stage 4: Layout, working out positions and sizes

The render tree knows which elements are visible and how they should be styled, but it does not yet know where they go or how big they are. The layout stage figures that out.

During layout (sometimes called “reflow”), the browser calculates the exact position and dimensions of every box on the page. It works out how wide the screen is, how text wraps, how much space each element takes, and where each one sits relative to the others. The result is a precise map of geometry: this paragraph starts at this coordinate and is this many pixels tall, this image sits here, and so on.

Stage 5: Paint, turning boxes into pixels

Now the browser knows what to draw and exactly where. The paint stage fills in the actual pixels: it draws text, colors, backgrounds, borders, shadows, and images into layers in memory. Think of layout as drawing the blueprint and paint as actually coloring it in.

Paint does not yet put anything on your screen directly. It produces the visual content, often broken into separate layers, ready to be assembled.

Stage 6: Compositing, assembling the final image

The last stage is compositing. The browser takes the painted layers and stacks them in the right order to produce the final image you see, then hands that to the screen.

Splitting the page into layers is a clever optimization. If only one layer changes, for example an element sliding across the screen, the browser can often just move that layer instead of repainting everything. This is part of why smooth animations are possible.

After compositing, the page is finally visible. The whole chain, from networking to compositing, is what the browser does for that first paint of any page you open.

The JavaScript engine, the part that changes everything

There is one more major player: the JavaScript engine. This is the component that runs the JavaScript code on a page (in Chrome it is called V8, in Firefox it is SpiderMonkey).

JavaScript matters here because it can reach into the pipeline and change things after the fact. A script can add a new element to the DOM, change an element’s style, or remove something entirely. When it does, the browser may need to redo layout, paint, and compositing for the affected parts. This is how interactive pages work: you click a button, JavaScript updates the DOM, and the browser re-runs the later stages to reflect the change.

// JavaScript reaching into the DOM to change the page
document.querySelector("h1").textContent = "Updated!";

That single line tells the browser the page changed, which can ripple back through layout and paint so you see the new text.

Putting it all together

Here is the whole story in one sentence: the browser downloads files, parses HTML into the DOM and CSS into the CSSOM, combines them into a render tree, lays out where everything goes, paints the pixels, and composites the layers into the final image, while the JavaScript engine can step in at any point to change the page.

A few ideas worth carrying with you:

• The stages run roughly in order, each feeding the next, but the browser is smart about overlapping work and starting downloads early.
• The DOM and CSSOM are the two foundations everything visual is built on.
• Changes after load, especially from JavaScript, can send the browser back through layout, paint, and composite.

This overview is deliberately shallow on purpose, so you can see the shape of the whole thing. From here, the natural next steps are to look more closely at how the rendering stages fit together, and at how browsers prioritize the work needed to show you something useful as fast as possible. Those deeper dives will build directly on the pipeline you just walked through.