How a Browser Works: A Beginner-Friendly Guide to Browser Internals
What happens when you type a URL and press Enter is more interesting than “the browser opens a website.” A browser is a small operating system of its own, with many parts working together to turn text files (HTML, CSS, JS) into the page you see and interact with.
What a browser really is
A browser (Chrome, Firefox, Edge, Safari) is a program that reads web content and turns it into a visual, interactive page.
Functions of browser:
Talks to servers on the internet.
Downloads HTML, CSS, JavaScript, images, fonts, etc.
Understands these files.
Builds an internal model of the page.
Draws pixels on your screen and updates them when things change.
So it’s not just “showing a website.” It’s fetching, understanding, and rendering.
Main parts of a browser
Here are the roles of each part roles:
User Interface (UI) – what you see: address bar, back/forward buttons, tabs, bookmarks.
Browser Engine – coordinator that connects the UI and the rendering engine.
Rendering Engine – reads HTML/CSS and turns them into the page layout and visuals.
Networking – handles HTTP/HTTPS requests and downloads.
JavaScript Engine – runs JavaScript code (V8 in Chrome, SpiderMonkey in Firefox, etc.).
Storage – cookies, localStorage, cache, etc.
How it all works together:
UI talks to you.
Networking talks to the internet.
Rendering engine and JS engine talk to the page.
Browser engine coordinates everyone.
User Interface: what you see and touch
The UI is the part you interact with:
Address bar – where you type
https://example.com.Tabs – let you open multiple pages at once.
Back / Forward buttons – move through your history.
Reload button – asks the page to load again.
Bookmarks – saved URLs.
These are not "the web page" itself. They are the controls around the web page. When you hit Enter in the address bar, the UI tells the browser engine: "Please load this URL in this tab."
Browser Engine vs Rendering Engine
These names are easy to mix up, so keep them simple:
Browser Engine: the manager. It receives instructions from the UI (load this URL) and tells the rendering engine what to do.
Rendering Engine: the builder and painter. It takes HTML/CSS and turns them into what you see on the screen.
Some common rendering engines:
Blink (Chrome, Edge, Opera)
WebKit (Safari)
Gecko (Firefox)
You don't need to know details. Just remember: browser engine = coordinator, rendering engine = page builder.
Networking: how the browser fetches data
After you press Enter:
The browser resolves the domain to an IP address using DNS.
It opens a TCP (or TLS for HTTPS) connection to the server.
It sends an HTTP request, e.g.
GET /for the main page.The server responds with HTML.
The networking part of the browser handles:
Making the connection.
Sending requests.
Receiving responses.
Handling redirects, errors, timeouts.
The networking layer then gives the downloaded HTML to the rendering engine.
The rendering pipeline: how your page comes to life
Now let's walk through the exact flow shown in the diagram, step by step.
Step 1: HTML Parser receives HTML
The browser receives raw HTML text from the network. The HTML Parser starts reading it character by character, breaking it into meaningful pieces called tokens.
Example:
<html>
<body>
<h1>Hello</h1>
<p>This is a page.</p>
</body>
</html>
The parser identifies:
Opening tags:
<html>,<body>,<h1>Closing tags:
</h1>,</p>,</body>Text content: "Hello", "This is a page."
Step 2: Content Sink coordinates the construction
As the HTML parser processes tokens, they flow into something called the Content Sink. Think of the Content Sink as a traffic controller that manages both HTML and CSS data flowing into the page construction.
The Content Sink:
Receives parsed HTML tokens from the HTML Parser.
Receives parsed CSS rules from the CSS Parser (which we'll talk about next).
Coordinates when and how the DOM and CSSOM get built.
This is where the two parallel streams (HTML and CSS) meet.
Step 3: CSS Parser processes stylesheets
While HTML is being parsed, the browser also finds <link> tags pointing to CSS files or <style> tags with inline CSS.
Example CSS:
h1 {
color: blue;
}
p {
font-size: 16px;
}
The CSS Parser:
Reads the CSS text.
Breaks it into tokens (selectors, properties, values).
Builds a structured representation of all the style rules.
This parsed CSS data flows into the CSSOM (CSS Object Model) via the Content Sink.
Step 4: DOM construction
Using the HTML tokens from the Content Sink, the browser builds the DOM (Document Object Model).
The DOM is a tree structure where each node represents an element, attribute, or piece of text:
html
└── body
├── h1
│ └── "Hello"
└── p
└── "This is a page."
Think of the DOM as a family tree of your page. Each element knows:
Its parent element.
Its children elements.
Its attributes and content.
JavaScript later uses this DOM to read or change the page dynamically.
Step 5: CSSOM construction
Parallel to DOM construction, the browser builds the CSSOM (CSS Object Model) from the parsed CSS rules.
The CSSOM is also a tree, organizing style rules by specificity and inheritance:
Rules:
h1 → { color: blue }
p → { font-size: 16px }
The CSSOM represents "what styles apply to what elements."
Step 6: Frame Constructor combines DOM and CSSOM
Now comes the crucial step. The browser has:
DOM – the structure and content.
CSSOM – the styles.
The Frame Constructor (also called the render tree builder) takes both and creates a frame tree (render tree).
The frame tree:
Only includes visible elements (skips
display: noneelements).Each node has both content and computed styles (final colors, fonts, sizes after inheritance and cascading).
Think of this as: "DOM + CSSOM = ready to layout and paint."
Step 7: Frame Tree / Reflow
The Frame Tree / Reflow stage is where the browser calculates:
Where each element should be positioned (X, Y coordinates).
How big each element should be (width, height).
How text wraps, how flex/grid containers arrange children, etc.
This is called layout or reflow.
Example:
<h1>might be at position (10px, 20px) with width 800px and height 40px.<p>might be at (10px, 70px) with width 800px and height 60px.
When something changes (window resize, DOM change, style change), the browser may need to recalculate layout—this is called triggering a reflow.
Step 8: Painting
Now that the browser knows:
What to draw (frame tree).
Where to draw it (layout).
The Painting stage actually draws pixels:
Backgrounds and colors.
Borders.
Text.
Images.
Shadows, gradients, etc.
Modern browsers often break the page into layers (like in Photoshop), paint each layer separately, and then composite them together.
Step 9: Display
Finally, the painted result goes to the Display stage, which sends the final image to your screen.
You see the fully rendered web page!
The complete flow
Here's the entire pipeline:
HTML → HTML Parser → tokens flow to Content Sink
CSS → CSS Parser → style rules flow to Content Sink
Content Sink coordinates construction of:
DOM (from HTML tokens)
CSSOM (from CSS rules)
Frame Constructor combines DOM + CSSOM → Frame Tree
Frame Tree / Reflow calculates positions and sizes (layout)
Painting draws pixels based on layout
Display shows the final result on your screen
What happens when things change
This pipeline doesn't just run once. When JavaScript changes the DOM or styles, parts of the pipeline run again:
Small style change (e.g., color) → may skip layout, just repaint.
Size or position change → triggers reflow (layout recalculation) + repaint.
Adding/removing elements → rebuilds part of DOM → reflow + repaint.
This is why performance matters: frequent DOM changes or layout-heavy operations can cause lag because the browser has to redo expensive steps.
Very basic idea of parsing
Parsing sounds scary, but it's just turning text into structure and meaning.
Take a simple math expression:
2 + 3 * 4
Raw text is just characters: 2, +, 3, *, 4.
To understand it, you:
Break it into tokens:
2,+,3,*,4.Apply rules: multiplication before addition.
Build a structure in your head:
2 + (3 * 4).
The browser does something similar with HTML and CSS:
Breaks text into tokens.
Applies grammar rules.
Builds trees (DOM and CSSOM).
You don't need to know the full grammar; just remember that parsing = understanding structured text.
As you build more web apps, these ideas will naturally become familiar. The goal is to have a mental picture of the flow, not perfect recall of all the parts. Understanding this pipeline helps you write better, faster web applications and debug rendering issues confidently.
