Browser

In short: A program that fetches HTML/CSS/JS documents from the web and displays them as a visible, interactive page.

In more detail: At its core, consists of a rendering engine (builds the visible layout from HTML/CSS) and a JavaScript engine (executes scripts). Well-known examples: Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge.

In Depth

Loading a web page roughly runs through phases: the browser resolves the entered URL to an IP address via DNS, establishes a TCP connection (usually over HTTPS), loads the HTML document, builds the DOM tree from it, loads referenced CSS and JS files, computes the layout, and finally draws pixels to the screen. On changes (e.g. through JavaScript), this layout/render cycle repeats for the affected parts of the page.

Today, essentially three rendering engines dominate the market: Blink (Chrome, Edge, Opera, Brave — all based on Chromium), Gecko (Firefox) and WebKit (Safari). This consolidation is controversial: on the one hand, it simplifies web development (fewer engines to test against), but on the other, Chromium’s market dominance means new web standards are often effectively driven by Google before other engines catch up — one reason independent engines like Firefox’s Gecko are considered important for competition on the web.

Browser history in broad strokes

The first graphical browser (Mosaic, 1993) laid the foundation for the World Wide Web as we know it today; its successor, Netscape Navigator, dominated the 1990s, until Microsoft’s Internet Explorer (through bundling with Windows) won the so-called “first browser war”. Firefox (born from Netscape’s legacy) brought real competition back in the 2000s, before Google Chrome quickly rose to market leadership from 2008 onwards, thanks to high speed and regular updates — a position it still holds by a clear margin today.

The rendering pipeline in detail

The process sketched in the short summary can be broken down further: from the HTML, the DOM (Document Object Model) is first built, and in parallel from the CSS, the CSSOM (CSS Object Model) — both are combined into the “render tree”, which contains only the actually visible elements. This is followed by “layout” (computing the exact position and size of every element) and finally “paint” (actually drawing the pixels). Changes that only affect appearance (e.g. a colour change via CSS) only require a new paint step; changes to size or position, by contrast, trigger a complete layout reflow, which is noticeably more expensive — one reason performance-focused web developers prefer implementing CSS animations via transform/opacity rather than width/top.

JavaScript engines and just-in-time compilation

Every rendering engine brings its own JavaScript engine (V8 for Blink/Chrome, SpiderMonkey for Gecko/Firefox, JavaScriptCore for WebKit/Safari). These no longer purely interpret JavaScript, but use just-in-time compilation: frequently executed code is detected at runtime and translated into optimised machine code, while rarely used code stays interpreted — a major reason modern JavaScript execution is orders of magnitude faster than 15 years ago.

See also: Browser Tab, Browser History, HTML, CSS