A browser is a translator and a drawing program
A web page arrives as plain text files. A browser’s job is to read those files, work out what they describe and draw the result on your screen, while also letting you click, type and scroll. Browsers such as Chrome, Firefox, Safari and Edge are large, complicated programs, but their core task can be described in a few steps.
The three main languages
Most pages are built from three kinds of code, each with a different role.
- HTML describes the content and structure: headings, paragraphs, links, images, forms and so on.
- CSS describes appearance: colors, fonts, spacing, and how the layout changes on different screen sizes.
- JavaScript adds behavior: responding to clicks, updating parts of the page, loading more data, running small applications.
A rough analogy is a house. HTML is the framing and rooms, CSS the paint and furniture arrangement, and JavaScript the wiring and moving parts.
Step 1: Fetching the files
After the address is looked up and a connection is set up, the browser requests the page. The server sends back an HTML document first. While reading it, the browser finds references to other resources, such as stylesheets, scripts, fonts and images, and asks for those too. Many of these requests are made at the same time, and the browser may reuse files it has saved from earlier visits, which is called caching.
Step 2: Building the document tree
The browser parses the HTML, which means it reads the text and builds an internal structure called the Document Object Model, or DOM. The DOM is a tree: the whole page is at the top, with branches for sections, then paragraphs, then individual words and images. Browsers are forgiving of mistakes in HTML and try to make sense of badly written code, which is one reason the web works despite plenty of sloppy pages.
At the same time, the browser parses the CSS into a similar structure describing the style rules.
Step 3: Working out styles and layout
The browser then combines the DOM with the style rules to determine how each element should look. This produces what is often called a render tree, which includes only visible elements. A hidden item is left out.
Next comes layout, sometimes called reflow. The browser calculates the size and position of every element: where each line of text breaks, how wide each column is, where each image sits. This depends on the window size, which is why the same page rearranges itself on a phone and on a large monitor.
Step 4: Painting and compositing
With positions known, the browser paints: it fills in pixels for text, backgrounds, borders and images. Complex pages are often drawn in separate layers, such as a fixed menu bar sitting above scrolling content. The graphics hardware then combines the layers into the final image in a step called compositing. Using the graphics chip for this makes scrolling and animation smoother.
Where JavaScript fits in
JavaScript can run while the page is being built, and it can change the DOM afterward. When it does, the browser may need to recalculate styles, layout or painting for the affected parts. Scripts that make many large changes can make a page feel sluggish. Scripts can also block the browser from continuing to build the page if they are written in a way that makes it wait, which is why many sites load non-essential scripts later.
Many modern sites send a nearly empty HTML file and let JavaScript build the page in the browser, fetching data from servers in the background through an API. Others build more of the page on the server so that text appears immediately. Both approaches are common, and each has trade-offs for speed and for search engines, which must also interpret the page.
What a user notices
Several visible behaviors come from this process.
- Text before images: text can be shown as soon as the HTML arrives, while images fill in later.
- Layout shifts: if an image or advertisement loads without reserved space, content may jump when it appears. Careful developers specify sizes in advance to prevent this.
- Flash of unstyled content: if styles arrive late, a page can briefly look plain before the formatting is applied. Browsers often delay painting until the CSS is ready to avoid this.
- Different looks in different browsers: browsers follow shared standards, but small differences in how they interpret the rules, or which new features they support, can cause pages to look or behave slightly differently.
Beyond drawing pages
Browsers do other important work. They manage tabs, usually keeping each in a separate process so that one crashing page does not take down the rest. They also enforce security rules, such as the same-origin policy, which stops a script on one site from freely reading data from another. They check certificates for secure connections and display warnings, and they store cookies, saved passwords and history. Some of these are discussed further in the pieces on browser cookies and digital privacy.
Browsers also include developer tools, opened with a menu option or a keyboard shortcut, that let anyone inspect a page’s HTML and CSS, watch network requests and see how long each step takes. They are a helpful way to see the process described here in action.
Why pages feel slow or fast
Page speed depends on how much has to be downloaded, how quickly the server responds, how many separate files are involved, how heavy the scripts are, and how powerful the device is. A page that looks simple can still be slow if it relies on large images or many third-party scripts. Improving it usually means sending less data, deferring what is not needed immediately, and letting the browser reuse saved files.
A note on terminology
People sometimes confuse the browser with the search engine or with the internet itself. The browser is only the program on your device that requests and displays pages. Search engines and websites are separate services, and the network that connects them is another layer entirely.