It feels instant.

But inside the browser, a whole pipeline runs—like a mini factory that turns a URL into pixels on your screen.

This article explains that pipeline in a visual, story-driven way (no heavy specs, no deep engine internals). You don’t need to memorize everything—just understand the flow.

1) What a browser actually is (beyond “it opens websites”)

A browser is not just a “website opener.”

A browser is a program that can:

• Request resources from the internet (HTML, CSS, JavaScript, images, fonts)
• Understand and parse those resources
• Build internal models of the page (DOM + CSSOM)
• Calculate where everything should go (layout)
• Draw it (paint)
• Update it as you interact (scroll, click, type, navigate)

In short:

A browser is a network client + document parser + layout engine + drawing engine + JavaScript runtime, all working together.

2) Main parts of a browser (high-level overview)

Browsers are built from multiple components that cooperate.

Here’s a high-level architecture view (names differ by browser, but the idea is similar across Chrome/Edge (Chromium), Firefox (Gecko), Safari (WebKit)).

High-level browser architecture (diagram)

flowchart LR
    UI[User Interface<br/>tabs, address bar, back/forward] --> BE[Browser Engine<br/>coordinates everything]
    BE --> NET[Networking<br/>HTTP requests, caching]
    BE --> RE[Rendering Engine<br/>HTML/CSS -> pixels]
    BE --> JS[JavaScript Engine<br/>runs JS code]
    RE --> DISPLAY[Display / GPU<br/>shows pixels on screen]
    NET --> RE
    NET --> JS

Don’t worry if these terms feel new—by the end, they’ll make sense as a sequence.

3) User Interface: address bar, tabs, buttons

The User Interface (UI) is what you interact with:

• Address bar (URL bar)
• Tabs
• Back/forward buttons
• Reload button
• Bookmarks
• DevTools

The UI itself doesn’t “render the web page.”
It mostly collects your intent (“go to this URL”) and sends it into the browser’s internal pipeline.

4) Browser Engine vs Rendering Engine (simple distinction)

These sound similar, so here’s an easy way to separate them:

Browser Engine (the coordinator)

• Think: manager / conductor
• Coordinates navigation, history, caching, and delegates work to other parts
• Connects UI actions (like pressing Enter) to the rest of the system

Rendering Engine (the page builder + painter)

• Think: builder + artist
• Takes HTML + CSS and turns them into what you actually see
• Builds DOM/CSSOM, computes layout, paints pixels

A rough mental model:

Browser Engine = "Make this navigation happen."
Rendering Engine = "Turn these files into a visible page."

5) Networking: how a browser fetches HTML, CSS, JS

After you press Enter, the browser needs to fetch resources.

At a very high level, networking often looks like this:

1. DNS lookup: “What IP address belongs to this domain?”
2. Connection: open a connection (TCP) and often secure it (TLS/HTTPS)
3. HTTP request: request / (or another path)
4. HTTP response: receive HTML (and later CSS/JS/images, etc.)
5. Caching: reuse cached resources when possible to speed things up

Full browser flow from URL to pixels (vertical)

flowchart TD
    A[Type URL + Enter] --> B[Check cache / service worker]
    B --> C[DNS lookup]
    C --> D[Connect (TCP) + Secure (TLS)]
    D --> E[HTTP request for HTML]
    E --> F[Receive HTML response]
    F --> G[Parse HTML -> DOM]
    G --> H[Discover CSS/JS/image links]
    H --> I[Fetch CSS/JS/images]
    I --> J[Parse CSS -> CSSOM]
    J --> K[DOM + CSSOM -> Render Tree]
    K --> L[Layout (reflow)]
    L --> M[Paint]
    M --> N[Display pixels on screen]

That’s the story arc of page loading: URL → files → models → layout → paint → pixels.

6) Very basic idea of parsing (simple math example)

Before we talk about HTML parsing, let’s understand “parsing” in everyday terms.

Parsing means:

Taking raw text and turning it into a structured meaning the program can work with.

Example: parse a math expression

Expression:

2 + 3 * 4

A computer can’t just “guess.” It needs structure. Typically * happens before +.

So the expression can become a tree like:

    (+)
   /   \
 (2)   (*)
      /   \
    (3)   (4)

That’s parsing: turning text into a structure (often a tree).

Keep that in mind—HTML parsing is similar, except it builds the DOM tree.

7) HTML parsing and DOM creation

When the browser receives HTML, it doesn’t display it immediately as text.
It parses it and builds a structured model called the DOM.

What is the DOM?

DOM = Document Object Model

In beginner terms:

The DOM is a tree of nodes representing the HTML structure.

Example HTML:

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

Becomes a tree conceptually like:

Document
└── html
    ├── head
    └── body
        ├── h1
        │   └── "Hello"
        └── p
            └── "Welcome"

HTML → DOM creation flow (diagram)

flowchart LR
    A[HTML text] --> B[HTML parser]
    B --> C[DOM tree]

Analogy:
DOM is like a family tree of your page—parents, children, siblings.

8) CSS parsing and CSSOM creation

CSS also gets parsed into a structured model called the CSSOM.

What is the CSSOM?

CSSOM = CSS Object Model

In beginner terms:

The CSSOM is a structured representation of CSS rules the browser can apply.

Example CSS:

p { color: blue; }
.card p { font-size: 18px; }

The browser turns that text into a model it can query efficiently.

CSS → CSSOM creation flow (diagram)

flowchart LR
    A[CSS text] --> B[CSS parser]
    B --> C[CSSOM]

Analogy:
If the DOM is the “list of parts,” the CSSOM is the “styling rulebook,” organized so the browser can apply it.

9) How DOM and CSSOM come together

The browser needs both:

• DOM: “What elements exist?”
• CSSOM: “What styles apply to them?”

When combined, the browser creates something called the Render Tree.

What is the Render Tree?

A simplified way to think about it:

The Render Tree is the set of visible things that need to be drawn, with their computed styles.

Important beginner note:

• The Render Tree is not always identical to the DOM.
• Some DOM nodes might not be visible (example: display: none).
• The Render Tree focuses on what gets painted.

DOM + CSSOM → Render Tree (diagram)

flowchart LR
    DOM[DOM] --> RT[Render Tree]
    CSSOM[CSSOM] --> RT

Big “tree” mental model

DOM (structure)         CSSOM (rules)
     \                    /
      \                  /
       ---- Render Tree ----
          (visible nodes +
           computed styles)

10) Layout (reflow), painting, and display

Once the Render Tree exists, the browser must figure out:

1) Layout (reflow)
Where does each element go?
How wide/tall is it?
What’s its position?

2) Paint
Draw pixels: text, colors, borders, images, shadows.

3) Display / Composite
Show the final result on your screen (often using GPU acceleration).

Render pipeline (diagram)

flowchart LR
    A[Render Tree] --> B[Layout / Reflow<br/>calculate positions & sizes]
    B --> C[Paint<br/>draw pixels]
    C --> D[Display / Composite<br/>final image on screen]

Simple analogy (layout vs paint)

• Layout = deciding where furniture goes in a room (measurements + positions)
• Paint = painting the walls and placing decorations (visual drawing)

11) Selector-level view: how files become pixels (end-to-end)

Here’s the whole thing again, but as a clean horizontal story:

flowchart LR
    U[URL Entered] --> N[Networking fetches HTML]
    N --> H[HTML parsed]
    H --> D[DOM built]
    D --> F[Find linked CSS/JS]
    F --> C[CSS fetched + parsed -> CSSOM]
    D --> R[DOM + CSSOM]
    C --> R
    R --> T[Render Tree]
    T --> L[Layout]
    L --> P[Paint]
    P --> S[Screen pixels]

If you understand that chain, you understand the browser at a practical level.

12) Where JavaScript fits (high-level)

JavaScript can:

• change the DOM (add/remove elements, change text)
• change styles (classes, inline styles)
• react to events (click, input, scroll)
• trigger new layout/paint when changes affect geometry or visuals

So the pipeline isn’t “one-time.” It repeats as the page updates.

A simplified mental loop:

JS changes DOM/CSS -> Render Tree updates -> Layout -> Paint -> Display

(You don’t need to memorize the details yet—just know JS can cause updates.)

13) Reassurance for beginners (what to remember vs what to revisit later)

You do not need to remember every term immediately.

If you remember only this flow, you’re already ahead:

1. Browser fetches HTML/CSS/JS
2. HTML becomes DOM
3. CSS becomes CSSOM
4. DOM + CSSOM become Render Tree
5. Render Tree goes through Layout → Paint → Display

Everything else is detail you can layer in later.

Summary (one-page cheat sheet)

• A browser is a system that turns web resources into pixels.
• UI is what you click/type in (tabs, address bar).
• Browser Engine coordinates the process.
• Rendering Engine turns HTML/CSS into a visual page.
• Networking fetches HTML/CSS/JS over the internet.
• HTML parsing builds the DOM (a tree).
• CSS parsing builds the CSSOM (a rule model).
• DOM + CSSOM create the Render Tree (visible styled objects).
• Render Tree → Layout (reflow) → Paint → Display.