What is a web browser? The definition, and what the engine underneath does

A definition, and what it leaves out

So, what is a web browser? The web browser definition that survives contact with the actual software is short: a program that fetches documents over the network and renders them for a person to read. What that definition leaves out is everything the browser has become since — an identity store holding your logins, a permission broker deciding which sites may use the camera, and a sandbox running untrusted code from strangers all day without incident.

Both halves matter. The narrow web browser definition explains the address bar and the back button; the wider one explains why almost every privacy question about a phone turns out to be a question about the browser. How does a browser work, then, once the definition is out of the way? In two stages, and the second is far larger than the first.

What is a web browser actually doing when you open a page?

Fetching. You type an address or follow a link. The browser resolves the domain name to a server, opens a connection (encrypted, on any site that matters) and requests the document.

Rendering. What arrives is text: HTML describing structure, CSS describing presentation, JavaScript describing behaviour. The browser parses all three, computes where every element goes, paints the result, and then keeps running the JavaScript for as long as you stay on the page.

The second job is far larger than the first, and it is why browsers are among the most complex pieces of software most people ever run. MDN’s account of how browsers populate a page follows the same pipeline in more detail, step by step.

The engine underneath

The rendering part is a separate component called the engine, and there are only three that matter: Blink (Chrome, Edge, Opera, Brave, Samsung Internet, Vivaldi), Gecko (Firefox) and WebKit (Safari).

This explains more about browser behaviour than branding does. Two browsers on the same engine render a page identically and support the same web features on the same schedule; they differ in interface, defaults and privacy posture, not in what the web can do inside them. It also explains why "works in Chrome, broken in Safari" is a real category of bug and "works in Chrome, broken in Edge" essentially is not.

On iPhone this mattered in an unusual way: for most of the platform's history Apple required every browser on iOS to use WebKit, so a browser labelled Chrome or Firefox on an iPhone was that company's interface over Apple's engine. Regulatory pressure in the EU has since forced that open, but the installed reality changes slowly.

Browser or search engine?

Ask what is a web browser and the follow-up is almost always whether Google is one. This is the single most common confusion about the subject, and it exists for a good reason: the address bar does both jobs. Type a web address and the browser fetches that page; type anything else and it hands the words to a search engine and shows you the results. One field, two behaviours.

The browser is the application installed on your device. The search engine is a website that the browser loads, like any other. Chrome is a browser made by Google; Google Search is a site you reach through it. You can use Chrome without ever touching Google Search, and you can use Google Search in Firefox or Safari.

The distinction matters practically, because the setting that decides which search engine receives what you type is a browser setting, and it is the one with the highest ratio of consequence to effort in the whole settings screen.

A short history, and why it explains the present

The first browser was written by Tim Berners-Lee in 1990, called WorldWideWeb and later renamed Nexus to avoid confusion with the thing it browsed. It was Mosaic in 1993, and Netscape after it, that turned the web into something ordinary people used.

What followed shaped the web permanently. Microsoft bundled Internet Explorer with Windows, won the market, and then largely stopped developing it, leaving a long stretch where the dominant browser was years behind the standards. Firefox emerged from Netscape's remains and broke that stall; Chrome arrived in 2008 and took the lead within a few years, on speed and on a release cadence nobody matched.

The lesson visible in that history is why engine diversity is discussed as seriously as it is. A single dominant engine means the web does what that engine's owner implements, and the Internet Explorer years are the worked example of how that goes.

Rendering is also not a single pass. The browser parses what has arrived so far, paints an incomplete page, and revises it as more of the document and its stylesheets and fonts land. Most of the visual instability people notice while a page settles is that revision happening in public, and it is why a slow connection makes a page feel worse than a slow computer does: the work is waiting on bytes rather than on the device. The layout shift you see at the end is usually one late stylesheet, one late font or one late advertisement arriving after the text has already been placed.

What the browser keeps

To avoid re-downloading everything, browsers store a great deal locally: a cache of files, cookies that keep you signed in, site data, history and saved passwords. Almost every privacy control in a browser is a rule about this store — what goes in, who may read it, and how long it survives. Incognito mode is the clearest example: it does not change how the page is fetched at all, only what is written down afterwards.

Browsers that do the work elsewhere

One family breaks the pattern by moving the rendering off the device entirely: a proxy browser fetches and lays out the page on the vendor's servers and sends the phone a compressed result. That design made the web usable on hardware that could not have rendered it, and it is the architecture the browser this domain once belonged to was built on — see BOLT Browser.

That design has not disappeared, it has changed names. Data-saver modes, VPN-style proxies built into browsers, and privacy proxies that hide your address from the destination all make the same structural trade: something in the middle handles the request, and you accept that it sees what passes through in exchange for what it gives back.

The work you never see

How does a browser work while a page just sits there, apparently doing nothing? Mostly not on layout. It is running untrusted code from strangers, thousands of times a day, and the fact that this is unremarkable is the result of a lot of engineering.

Sandboxing. Each site runs in its own isolated process with almost no access to your machine. A page cannot read your files, look at another tab, or reach the operating system except through narrow, permission-gated interfaces. When you see a browser use a surprising amount of memory, this is largely why — isolation costs processes.

Certificate validation. Before showing a page over HTTPS the browser checks that the certificate is valid, current, and issued by an authority it trusts for that domain. The warning page you occasionally hit is that check failing, and it is one of the few warnings genuinely worth not clicking through.

Same-origin enforcement. Code from one site cannot read data from another. Nearly every serious web vulnerability class is a way around this rule, and nearly every browser security update is a repair to it.

Malware and phishing warnings. The full-page red interstitial comes from a reputation service (Google Safe Browsing in most browsers) checked against the address before the page loads.

How a browser decides what to trust

Before any of the rendering work starts, the browser has to establish that the server on the other end is the one the address names. That is what the padlock is reporting. The server presents a certificate; the browser checks that it covers the hostname you asked for, that it has not expired, and that it chains to a certificate authority in the trust store the browser ships. If any of those fails the page does not load quietly with a warning icon, it is replaced by a full-page interstitial, because a failure here means you may not be talking to whom you think.

Once the connection is established, the browser polices what the page may pull into it. A page served over HTTPS that asks for a script over plain HTTP is mixed content, and the script is blocked outright rather than loaded, since an attacker able to alter it could rewrite the whole page. Images in the same position are usually upgraded or blocked more gently. This is also why HTTPS-only mode is a meaningful setting rather than a cosmetic one: it moves the browser from accepting an unencrypted connection silently to asking you first.

The same-origin policy sits underneath all of it. Code from one origin cannot read the contents of another, which is what stops a page in one tab from reading your mail in the next. Almost every deliberate exception to that rule, from CORS headers to the permissions a site must request for the camera, is a narrow, explicit opening in an otherwise closed wall.

What the address bar is actually parsing

The thing this site is named after does more than hold text. What you type is parsed into parts: a scheme that selects the protocol, a host that gets resolved to an address, an optional port, a path, a query string and a fragment. The fragment after the hash never leaves the device, which is why a link to a section of a page tells the server nothing about which section you wanted. The query string does leave, which is why tracking parameters live there.

The address bar is also a search box, and that dual role is the source of a genuine privacy question. Anything it cannot confidently parse as a URL is sent to your search provider, and on most browsers keystrokes are sent as you type in order to offer suggestions. A single mistyped internal hostname can therefore end up as a search query. Turning search suggestions off is the one setting that stops it, at the cost of the suggestions themselves.

Tabs, profiles and sync

Three organising features are worth understanding because people routinely use the wrong one.

Tabs are just open pages. Profiles are separate identities inside one browser: their own history, bookmarks, extensions, cookies and saved passwords. Two profiles never see each other's sign-ins, which makes them the correct tool for keeping work and personal accounts apart, and a better one than incognito mode, which people often reach for instead and then have to re-authenticate every session.

Sync copies a profile between your devices. It is convenient and it has a consequence worth knowing: clearing data on one device may propagate, and signing into a browser on someone else's machine puts your history and passwords there. Both are reversible, and both surprise people who assumed a browser was purely local.

Engine version matters more than engine name, which is the practical reason a browser that stops updating becomes a problem quickly. Web features arrive continuously, and a page written against one that shipped last year simply does not work on a build from two years ago. On a phone this is usually invisible, because the browser updates itself through the store; on an old device that no longer receives those updates it is the real reason sites start breaking, and no setting inside the browser can compensate for it.

Choosing one

For most people the choice is between defaults that are already good. The questions worth asking are narrow: does it run the engine your platform handles best, does it sync to the other devices you use, and are its privacy defaults the ones you would have chosen.

What almost never justifies switching is a speed claim. On the same engine, performance differences are marginal and situational. On different engines they are real but small compared with the effect of your connection, the site's own weight, and how much of your stored data the browser has to carry — which is why what the browser stores affects your daily experience more than which logo is on it.