How a Browser Works: A Beginner-Friendly Guide to Browser Internals
Every day, you type a URL into your browser and a webpage appears.
It feels instant. It feels simple.
It is not.
A browser is one of the most complex pieces of software on your computer. And most people who use it every day — including a lot of developers — have no idea what is actually happening under the hood.
So let's fix that.
What Actually Is a Browser?
Most people would say: "It's the thing I use to open websites."
That is technically correct. But it is like saying a car is "the thing I use to get to work." It is true, but it tells you nothing about how it actually functions.
A browser is a software application that takes a URL, fetches the resources at that address, interprets them, and displays a visual result on your screen.
That process involves networking, parsing, layout calculation, painting, and a lot more — all happening in the time it takes you to blink.
To understand how, you first need to understand what a browser is made of.
The Main Parts of a Browser
A browser is not a single thing. It is a collection of components, each responsible for a specific job.
Here is the high-level picture:
User Interface — everything you see and interact with. The address bar, the back button, the tabs, the bookmarks bar.
Browser Engine — the coordinator. It sits between the UI and the rendering engine and manages the flow.
Rendering Engine — the part that actually reads HTML and CSS and figures out what to show on screen.
Networking — handles all the HTTP requests. When you type a URL, this is the part that goes and fetches the HTML from the server.
JavaScript Interpreter — reads and executes JavaScript. Browsers like Chrome use engines like V8 for this.
UI Backend — draws basic things like dropdowns and input boxes using the operating system's native UI.
Disk API (Data Storage) — lets the browser store things locally. Cookies, localStorage, cached files.
Each of these components has a specific job. They do not work in isolation — they hand off to each other in a sequence. And that sequence is what turns a URL into a webpage.
Step 1: You Type a URL and Press Enter
The moment you press Enter, the Networking component kicks in.
It takes the URL, figures out the IP address through DNS, connects to the server, and sends an HTTP request. The server responds with HTML.
That raw HTML text is now sitting in memory. The browser needs to make sense of it.
Step 2: HTML Parsing and the DOM
The browser passes the raw HTML to the HTML Parser.
The parser reads the HTML line by line and builds a tree structure called the DOM — the Document Object Model.
Think of the DOM as the browser's internal representation of your webpage. Not the visual page — just a structured model of every element, every tag, every piece of content.
If your HTML looks like this:
html
<html>
<body>
<h1>Hello</h1>
<p>World</p>
</body>
</html>
```
The DOM is a tree that looks roughly like:
```
Document
└── html
└── body
├── h1 → "Hello"
└── p → "World"
```
This tree is what JavaScript can later interact with. When you do `document.getElementById()` in JS, you are reaching into the DOM.
---
## Step 3: CSS Parsing and the CSSOM
While HTML is being parsed, the browser also encounters `<link>` tags pointing to CSS files. The Networking component fetches those too.
The CSS is then passed to the **CSS Parser**, which builds its own tree called the **CSSOM — the CSS Object Model**.
The CSSOM is similar to the DOM but for styles. It maps every element to its computed styles — font size, colour, margin, display type, everything.
So after these two steps, the browser has two separate trees:
- A **DOM** that knows the structure and content of the page
- A **CSSOM** that knows how every element should be styled
Neither one alone is enough to render the page.
---
## Step 4: Bringing DOM and CSSOM Together
The browser combines the DOM and the CSSOM into what is called the **Render Tree**.
The Render Tree only contains the elements that will actually be visible on screen. Elements with `display: none` are excluded. The `<head>` tag is excluded. Only what needs to be painted makes it into the Render Tree.
Each node in the Render Tree carries both the content information from the DOM and the style information from the CSSOM.
Now the browser knows *what* to show and *how* it should look.
---
## Step 5: Layout (Reflow)
Knowing what to show and how it looks is still not enough. The browser also needs to know *where* everything goes.
This stage is called **Layout**, sometimes called **Reflow**.
The browser walks through the Render Tree and calculates the exact position and size of every element on the screen. It figures out where the heading starts, how wide the paragraph is, how far down the image sits.
This is where percentages get turned into actual pixel values. Where `width: 50%` becomes `width: 640px` based on the actual screen size.
---
## Step 6: Painting and Display
Once the browser knows what to show, how it should look, and where it should be — it paints it.
**Painting** is the process of filling in actual pixels. Background colours, text, borders, shadows — all of it gets drawn onto layers.
After painting, the **Display** step composites those layers and puts the final result on your screen.
That is the page you see.
---
## A Quick Note on Parsing
You might have noticed the word "parsing" appearing a lot. HTML parsing, CSS parsing.
Parsing is the process of taking raw text and turning it into a structured format the computer can actually work with.
A simple way to understand it: imagine the expression `1 + 2 * 3`.
To a human, this is obvious. But to a computer, it is just a string of characters. The parser reads it, understands the structure and the rules (multiplication before addition), and builds a tree:
```
+
/ \
1 *
/ \
2 3
Now the computer can evaluate it correctly. The tree captures the meaning, not just the text.
That is exactly what HTML and CSS parsers do. They take raw text and turn it into structured trees — the DOM and the CSSOM — that the rest of the browser can actually use.
Putting It All Together
Here is the full journey from URL to webpage:
You type a URL and press Enter
Networking fetches the HTML from the server
HTML Parser reads the HTML and builds the DOM
CSS Parser reads the CSS and builds the CSSOM
Browser combines them into the Render Tree
Layout calculates the position and size of every element
Painting fills in the actual pixels
Display puts it all on your screen
Every single time you load a webpage, this entire process runs.
Final Thoughts
A browser is not magic. It is a very well-engineered system made up of components that each do one specific job and hand off to the next.
Understanding this changes how you think about frontend development. Why does JavaScript block rendering sometimes? Because the JS interpreter is part of the same pipeline. Why does CSS matter for performance? Because CSSOM construction is a step the browser cannot skip.
Once you understand the internals, a lot of things that used to seem like random quirks start to make complete sense.
Thanks for reading.
