A rendering engine is the part of a web browser that takes HTML, CSS, and other web page resources and turns them into the visual page you see on screen. Every time you load a website, the rendering engine reads the code behind that page and figures out exactly what to display, where to place it, and how it should look.
You never interact with a rendering engine directly, but it’s doing the heavy lifting every second you browse the web. Understanding how it works helps explain why some pages load slowly, why the same website can look slightly different across browsers, and why web developers care so much about which engine their users are running.
How a Rendering Engine Turns Code Into a Web Page
When your browser receives the raw HTML for a page, the rendering engine kicks off a sequence of steps often called the critical rendering path. Each step builds on the last, moving from raw text to pixels on your screen.
First, the engine parses the HTML and converts it into something called the DOM tree (Document Object Model). This is a structured map of every element on the page: headings, paragraphs, images, buttons, links. The process is incremental, meaning the engine starts building this tree as soon as bytes arrive rather than waiting for the entire file to download. Raw HTML bytes become tokens, tokens become nodes, and nodes form the tree.
While building the DOM, the engine also encounters style information, either embedded in the HTML or linked as separate CSS files. It parses those styles into a parallel structure called the CSSOM (CSS Object Model), which maps out every visual rule: colors, fonts, spacing, borders, and more.
Next, the engine combines the DOM and CSSOM into a render tree. The render tree captures both content and styles but only includes elements that are actually visible. A hidden element won’t appear in the render tree even though it exists in the DOM.
With the render tree in place, the engine performs layout (sometimes called “reflow”). This is where it calculates the exact size and position of every element on the page relative to the screen dimensions. A paragraph’s width, a sidebar’s position, the spacing between images: all of that gets resolved during layout.
The final step is painting. The engine draws the actual pixels to the screen, filling in colors, text, borders, shadows, and images based on all the calculations from the previous steps.
Rendering Engine vs. JavaScript Engine
Browsers contain two distinct engines that work alongside each other. The rendering engine handles HTML and CSS, turning structure and style into visuals. The JavaScript engine handles code execution, running the scripts that make pages interactive: dropdown menus, form validation, dynamic content loading, animations triggered by user clicks.
Chrome, for example, uses the Blink rendering engine paired with a JavaScript engine called V8. Firefox uses the Gecko rendering engine alongside a JavaScript engine called SpiderMonkey. The two engines communicate constantly. When JavaScript modifies the page (say, by adding a new element or changing a color), it updates the DOM, which triggers the rendering engine to recalculate layout or repaint the affected area.
Which Browsers Use Which Engine
There are three major rendering engines powering nearly every browser in use today:
- Blink powers Google Chrome, Microsoft Edge, Opera, Samsung Internet, Brave, and most other Chromium-based browsers. Based on browser market share data, Blink-based browsers collectively account for roughly 78% of global web traffic.
- WebKit powers Apple’s Safari and is required for all browsers on iOS, even if those browsers use a different engine on other platforms. Safari holds about 16% of global browser usage.
- Gecko powers Mozilla Firefox and its forks. Firefox sits at around 2.3% market share globally.
Blink actually started as a fork of WebKit back in 2013, so the two engines share historical roots but have diverged significantly since then. Microsoft used to maintain its own engine called EdgeHTML but switched Edge to Chromium (and therefore Blink) in 2020.
This consolidation means web developers primarily test against two or three engines rather than a dozen, but it also raises concerns about one engine having outsized influence over web standards.
Reflow and Repaint: Why Pages Slow Down
After a page first loads, the rendering engine doesn’t stop working. Every time something on the page changes, the engine has to update what you see. These updates fall into two categories, and one is far more expensive than the other.
A reflow (also called a layout recalculation) happens when something changes the size or position of an element. Resizing a container, adding a new paragraph, toggling an element from hidden to visible: all of these trigger reflow. The costly part is that the engine can’t just recalculate the changed element. It often has to recalculate the position of every surrounding element too, since shifting one box on the page can push everything else around. On complex pages with thousands of elements, frequent reflows are one of the biggest causes of sluggish performance.
A repaint is lighter. It happens when a visual property changes without affecting layout, like switching a background color, adjusting opacity, or changing a border color. The engine redraws the affected pixels but skips the expensive position calculations.
Every reflow triggers a repaint, but not every repaint requires a reflow. This distinction is why well-optimized websites try to batch their changes and avoid layout-triggering properties during animations.
How GPU Acceleration Fits In
Modern rendering engines don’t rely solely on your computer’s main processor. They offload certain tasks to the GPU (graphics processing unit), which is designed to handle massive numbers of visual calculations simultaneously. GPUs excel at parallel processing, making them especially effective for tasks like applying visual effects, handling transparency layers, and compositing the final image from multiple painted layers.
When a browser “hardware accelerates” an animation, it means the rendering engine has handed that work to the GPU rather than recalculating it on the CPU every frame. This is why CSS animations that use properties like transforms and opacity tend to run much smoother than animations that change width or height. The transform-based animation can be composited entirely on the GPU, while width changes force the CPU-bound layout step to re-run.
Browsers communicate with the GPU through graphics APIs like OpenGL, Vulkan, and DirectX, though this happens behind the scenes without any action from the user.
Why Different Engines Produce Different Results
Each rendering engine interprets web standards independently, and while the major engines agree on the vast majority of cases, subtle differences exist. A font might render slightly differently in WebKit than in Blink. A CSS property that works perfectly in Gecko might behave unexpectedly in an older version of WebKit. These differences are the reason web developers test their sites across multiple browsers.
The rendering engine also determines which newer web features a browser supports. When a new CSS capability is proposed, each engine team decides when and how to implement it. This is why you’ll sometimes see a feature work in Chrome months before it arrives in Safari, or vice versa. Websites like “Can I Use” track exactly which features each engine supports, giving developers a way to check compatibility before relying on newer technology.