DEV Community

Cover image for How Does the Browser Turn Code Into Pixels?
Tanu Priya
Tanu Priya

Posted on

How Does the Browser Turn Code Into Pixels?

When you build a website, you write code like this:

<h1>Welcome</h1>
<p>This is my website.</p>
<button>Get Started</button>
Enter fullscreen mode Exit fullscreen mode
h1 {
  font-size: 48px;
  color: blue;
}
Enter fullscreen mode Exit fullscreen mode
button.addEventListener("click", () => {
  console.log("Clicked!");
});
Enter fullscreen mode Exit fullscreen mode

But your screen doesn't understand HTML.

It doesn't understand CSS.

And it doesn't understand JavaScript.

Your screen understands one thing:

Pixels.

So how does this:

HTML + CSS + JavaScript
Enter fullscreen mode Exit fullscreen mode

become this?

A complete website on your screen
Enter fullscreen mode Exit fullscreen mode

The browser has to process your code through a rendering pipeline:

HTML → DOM
CSS → CSSOM
       ↓
   Render Tree
       ↓
     Layout
       ↓
     Paint
       ↓
   Composite
       ↓
Pixels on Screen
Enter fullscreen mode Exit fullscreen mode

Let's see what actually happens behind the scenes.


1. HTML Creates the Structure

Everything starts with HTML.

Suppose the browser receives:

<body>
  <h1>Hello World</h1>
  <p>Welcome to my website.</p>
</body>
Enter fullscreen mode Exit fullscreen mode

The browser doesn't simply display this code directly.

Instead, it parses the HTML and creates a tree-like structure called the DOM.

DOM = Document Object Model

        BODY
       /    \
     H1      P
     |       |
  Hello    Welcome
Enter fullscreen mode Exit fullscreen mode

The DOM represents the structure of the webpage.

It tells the browser:

  • What elements exist
  • How those elements are connected
  • What content they contain

At this point, the browser knows what the page contains.

But it still doesn't know how anything should look.


2. CSS Defines How Everything Should Look

Now the browser processes CSS.

h1 {
  color: blue;
  font-size: 48px;
}

p {
  color: gray;
}
Enter fullscreen mode Exit fullscreen mode

The browser converts these styling rules into another structure called the CSSOM.

CSSOM = CSS Object Model

You can think of it like this:

DOM
"What exists on the page?"

CSSOM
"How should it look?"
Enter fullscreen mode Exit fullscreen mode

The CSSOM contains styling information such as:

  • Colors
  • Fonts
  • Sizes
  • Margins
  • Padding
  • Borders
  • Positioning
  • Visibility

Now the browser has two important pieces of information:

DOM  → Structure
CSSOM → Styles
Enter fullscreen mode Exit fullscreen mode

The next step is combining them.


3. DOM + CSSOM Create the Render Tree

The browser combines the DOM and CSSOM to create the Render Tree.

       DOM
        +
      CSSOM
        ↓
   Render Tree
Enter fullscreen mode Exit fullscreen mode

The Render Tree represents the elements that actually need to be rendered on the screen.

Here's an interesting example:

<h1>Hello</h1>
<p>Welcome</p>
Enter fullscreen mode Exit fullscreen mode
p {
  display: none;
}
Enter fullscreen mode Exit fullscreen mode

The paragraph still exists in the DOM.

But because it isn't visible, it doesn't need to be rendered.

So:

DOM
= All elements in the document

Render Tree
= Elements that need to appear visually
Enter fullscreen mode Exit fullscreen mode

Now the browser knows:

What should appear and how it should look.

But one major question still remains:

Where should everything go?


4. Layout Calculates the Exact Position of Everything

This stage is called Layout.

The browser calculates the exact geometry of every visible element.

For every element, it needs to determine things like:

Width
Height
Position
Spacing
Enter fullscreen mode Exit fullscreen mode

Imagine a simple webpage:

+----------------------------------+
|              Header              |
+----------------------------------+
|                                  |
|           Main Content           |
|                                  |
+----------------------------------+
|              Footer              |
+----------------------------------+
Enter fullscreen mode Exit fullscreen mode

The browser needs to calculate:

Where does the header start?
How wide is it?
How tall is it?

Where does the main content begin?
How much space does it take?

Where exactly should every piece of text appear?
Enter fullscreen mode Exit fullscreen mode

In other words:

Render Tree
     ↓
Layout
     ↓
Exact size and position of every element
Enter fullscreen mode Exit fullscreen mode

After this stage, the browser knows the complete geometry of the page.

Now it is finally ready to draw it.


5. Paint Turns the Page Into Visual Elements

The Paint phase is where the browser draws the visual parts of the page.

This includes:

  • Text
  • Colors
  • Backgrounds
  • Borders
  • Images
  • Shadows

For example:

.card {
  background: white;
  border: 1px solid #ddd;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}
Enter fullscreen mode Exit fullscreen mode

Layout determines:

"The card goes here and has these dimensions."

Paint determines:

"Now draw its background, border and shadow."

You can think of it like this:

Layout
= Where does it go?

Paint
= What does it look like?
Enter fullscreen mode Exit fullscreen mode

The browser now creates the visual output needed to display the page.

But modern browsers have one more important step.


6. Composite Combines Everything Together

A webpage is often split into multiple layers.

For example:

Background
    +
Content
    +
Images
    +
Fixed Header
    +
Animated Elements
Enter fullscreen mode Exit fullscreen mode

During Compositing, the browser combines these layers to produce the final image on your screen.

Painted Layers
      ↓
   Composite
      ↓
Final Page
Enter fullscreen mode Exit fullscreen mode

This is especially important for animations.

Some changes can be handled by moving or transforming existing layers instead of recalculating the entire page.

For example:

transform: translateX(100px);
Enter fullscreen mode Exit fullscreen mode

That's why certain animations can be much smoother than others.


Where Does JavaScript Fit Into This Process?

JavaScript can change the webpage at any time.

For example:

document.querySelector("h1").textContent = "Welcome Back!";
Enter fullscreen mode Exit fullscreen mode

Now the browser has to update what appears on the screen.

Or:

element.style.width = "500px";
Enter fullscreen mode Exit fullscreen mode

Changing the width can affect the layout of other elements.

The browser may need to perform work again:

JavaScript changes something
        ↓
Style recalculation
        ↓
Layout
        ↓
Paint
        ↓
Composite
Enter fullscreen mode Exit fullscreen mode

This is why JavaScript can have a major impact on frontend performance.

If your application repeatedly changes many elements, the browser may repeatedly perform expensive rendering work.


A Small Change Can Trigger Different Amounts of Work

This is one of the most important things to understand.

Imagine changing:

color: red;
Enter fullscreen mode Exit fullscreen mode

The browser may only need to update the visual appearance.

But changing:

width: 500px;
Enter fullscreen mode Exit fullscreen mode

can affect the layout.

And that may affect other elements around it.

So the browser may need to do more work:

Style
  ↓
Layout
  ↓
Paint
  ↓
Composite
Enter fullscreen mode Exit fullscreen mode

This is why not every visual change has the same performance cost.

Understanding the rendering pipeline helps you understand why some updates are cheap and others are expensive.


The Complete Journey

Let's put everything together.

HTML
  ↓
Browser creates the DOM
  ↓
CSS
  ↓
Browser creates the CSSOM
  ↓
DOM + CSSOM
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Composite
  ↓
Pixels on Your Screen
Enter fullscreen mode Exit fullscreen mode

JavaScript can interact with this pipeline at different points by changing:

  • Content
  • Styles
  • Elements
  • Dimensions
  • Positions

And depending on what changes, the browser may need to update part of the rendering process again.


A Real-World Example

Suppose you create a simple card:

<div class="card">
  <h1>Hello</h1>
  <p>Welcome to my website.</p>
</div>
Enter fullscreen mode Exit fullscreen mode
.card {
  width: 300px;
  padding: 20px;
  background: white;
  border-radius: 12px;
}
Enter fullscreen mode Exit fullscreen mode

The browser roughly goes through this journey:

1. Read HTML
        ↓
2. Create DOM
        ↓
3. Read CSS
        ↓
4. Create CSSOM
        ↓
5. Create Render Tree
        ↓
6. Calculate Layout
   - Width: 300px
   - Padding: 20px
   - Text positions
   - Final height
        ↓
7. Paint
   - Background
   - Text
   - Border radius
        ↓
8. Composite
        ↓
9. Display Pixels on Screen
Enter fullscreen mode Exit fullscreen mode

And this entire process happens incredibly fast.


Why Should Frontend Developers Understand This?

Because many performance problems are directly connected to this pipeline.

A slow website isn't always caused by "slow code."

Sometimes the browser is simply being forced to do too much work.

For example:

Too many style changes
        ↓
More rendering calculations

Frequent size or position changes
        ↓
More layout work

Complex visual effects
        ↓
More painting work

Heavy animations
        ↓
More compositing work
Enter fullscreen mode Exit fullscreen mode

Once you understand this pipeline, you can start debugging performance more intelligently.

Instead of saying:

"The page feels slow."

You can ask:

  • Is JavaScript causing too many updates?
  • Is the browser recalculating layout too often?
  • Are too many elements being repainted?
  • Is this animation forcing unnecessary work?
  • Can I reduce what the browser needs to render?

That is where frontend development starts becoming much more interesting.


The Most Important Way to Remember It

Think of the browser as a factory.

HTML
↓
Creates the structure

CSS
↓
Adds the design

Render Tree
↓
Decides what should appear

Layout
↓
Calculates where everything goes

Paint
↓
Draws everything

Composite
↓
Combines everything together

Pixels
↓
What you finally see
Enter fullscreen mode Exit fullscreen mode

Every button, image, card and animation on a website goes through some version of this journey before it reaches your screen.


Final Thought

When you look at a website, you see:

Text
Images
Buttons
Cards
Animations
Enter fullscreen mode Exit fullscreen mode

But the browser sees:

Code
  ↓
Structure
  ↓
Styles
  ↓
Render Tree
  ↓
Layout
  ↓
Paint
  ↓
Composite
  ↓
Pixels
Enter fullscreen mode Exit fullscreen mode

So the next time you open a website, remember:

Your browser isn't showing HTML and CSS.

It is constantly converting your code into millions of carefully calculated pixels.


Top comments (0)