What Is a Browser, and What It Quietly Stores for You

A browser is a program that fetches pages and displays them. That definition was complete for about fifteen years and it is now the least interesting part of the answer. For anyone whose mail, chat, documents, tickets and dashboards all live behind a URL, the browser stopped being a viewer and became the place the work is kept. The parts that matter most are the ones that never appear on screen.

Four jobs run at once inside any browser. Two of them produce what is visible. The other two produce almost every problem worth understanding.

The four jobs

Fetching. The browser opens a connection to a server, requests a document, and receives the HTML, the stylesheets, the images and the scripts that go with it. Everything after this point is local work.

Rendering. An engine parses the markup and the styles and builds the layout, then runs the JavaScript that makes the page behave rather than just sit there. This is where processing power goes.

Storing. Cookies, local storage, cached files, saved passwords, history and site settings all land on the disk. Sign-in state persists because of this job, and so do draft text, scroll positions and interface preferences on individual sites.

Extending. Extensions are allowed to observe and modify pages, subject to permissions. This job is optional and it is the one most often blamed for behaviour that actually belongs to the third.

Resource use also becomes legible once the jobs are separated. An open page costs memory because the rendered layout and the running script state are held rather than recomputed. That cost is wildly uneven. A finished article sitting in a tab holds a static layout and nothing else. A chat client in the next tab is maintaining an open connection, receiving messages, redrawing a list and running timers, for as long as it stays open. Counting tabs predicts very little; counting how many of them are alive predicts almost everything.

The same split explains why closing tabs sometimes helps immediately and sometimes does nothing. Modern browsers release resources from tabs that have been idle, so the twenty reference pages left open since Tuesday may already have been put to sleep. Closing those frees very little. The four applications that never go idle are the ones holding the memory, and they are usually the four nobody is willing to close.

Visible quality comes from the first two. Confusion comes from the third. Which account a page opened under, why a session disappeared overnight, why a second window shows the same identity as the first: all of it is the storing job, and none of it is visible in the interface.

A browser is not a search engine, and not a website

These get used interchangeably in conversation and they sit at different layers. The browser is an application running on the Mac. A search engine is a service running on someone else's servers, presented as one of the websites the browser displays. Typing into the address bar blurs the boundary, because that field does two unrelated things depending on whether the text parses as an address.

The distinction matters because it decides what to change when something is wrong.

The complaint	The layer it belongs to
Results are poor or full of noise	The search service
Everything feels slow with many tabs open	The local application and machine resources
A site keeps signing out	Local storage, or the service's session policy
A page renders incorrectly	The engine and the site's implementation
The wrong account opens from a link	The service's account resolution

Switching browsers to fix a search complaint changes nothing. Switching search engines to fix a memory complaint changes nothing either.

Underneath the names, there are three engines

There are many browsers and very few rendering engines. Chrome, Edge, Brave, Vivaldi and Opera all sit on Blink, by way of the shared Chromium codebase. Safari uses WebKit. Firefox uses Gecko.

That fact reframes most browser comparisons. Claims about speed and compatibility are usually claims about the engine, and between two products on the same engine those claims cancel out. What genuinely differs is everything built above it: how tabs are arranged, how profiles work, what is blocked by default, how much the browser talks to its vendor, and whether more than one identity is treated as a normal case.

It also explains why a site that renders badly in one browser often renders badly in three. Chrome, Edge, Brave and Vivaldi are not four independent verdicts on a page. They are one verdict repeated. Testing a broken layout is only informative when the second browser comes from a different family, which in practice means checking in Safari or Firefox rather than in another Chromium product.

Engine family also predicts how much a migration costs. Moving between two Chromium browsers usually carries extensions, bookmarks and saved passwords across with little friction. Moving to a different engine family means some extensions have no equivalent, and the switch takes an afternoon rather than ten minutes.

The user agent, and why a site says it is unsupported

Part of the fetching job is announcing what is asking. That announcement, the user agent, names the browser, its version and the operating system. Sites read it to adapt their layout, and some read it to refuse service.

Internal business systems are the usual place this surfaces. A page declares that only one browser is supported, even though it works correctly. The judgement is made on the server, using a string, so the fix is rarely on the local machine. Checking what the system actually requires is more productive than installing a browser to satisfy a version check.

Where sign-in actually lives

This is the single most useful thing to understand about a browser in a working context. The cookie that keeps a session alive does not belong to a tab and it does not belong to a window. It belongs to a profile, which is a storage area on disk.

Two windows opened from the same profile share everything. Signing into a second account in one of them replaces or joins the first, because both windows read the same jar. The intuition that a separate window means a separate session is simply wrong, and a great deal of wasted troubleshooting starts there.

Browsers offer different ways to create a second storage area.

• Chromium browsers and Safari provide profiles, each with its own cookies, extensions, history and settings, each running in its own window.
• Firefox provides profiles and also containers, which draw the boundary around a tab rather than a window, so two identities can sit side by side in one window.
• Private and incognito windows are temporary storage that is discarded when the last one closes, which makes them useful for a quick check and unsuitable for daily work.

Choosing between them comes down to how long the second identity needs to live. Something used for ten minutes belongs in a private window. Something used every day belongs in a profile or a container, because a storage area that clears itself means signing in again every morning. The mistake that costs the most time is treating a temporary mechanism as a permanent arrangement, then blaming the browser for losing sessions it was designed to discard.

Two limits deserve stating. A profile is a separation, not a lock: anyone able to use the Mac can switch into any profile configured on it, so this prevents mistakes rather than protecting access. And storage holds more than sign-in, so clearing browsing data to fix a problem also discards drafts, map positions, editor settings and reading positions across every site.

From reading documents to holding a workday

Early browsers were built around a simple loop: open, read, close. The interface still assumes it. Tabs sit in a single horizontal strip because a handful of documents fit there comfortably. History is ordered by when a page was visited, which is a sensible way to find an article read last Tuesday.

None of those assumptions describe a day spent inside twelve permanently open applications. A strip that holds five documents legibly holds fifteen tools as a row of identical favicons. Chronological history is close to meaningless for something opened every hour since March. Profiles assume one person with one identity, not one person with four.

There is a related mismatch in how sessions are meant to end. A browser assumes closing is normal and cheap, which is true for documents. It is not true for a queue of support tickets with three drafts in progress, and it is not true for a console that takes two authentication steps to reopen. Once closing carries a real cost, the browser is being asked to behave like an operating system while presenting itself as a document reader.

Vendors have added layers in response: tab groups, vertical tab strips, workspace features, and ways of installing a website so it opens in its own window with its own icon. Each is an attempt to put a stable structure on top of a design meant for reading. The boundary between a browser and an application has thinned enough that a fair share of the applications in the Dock are browsers wearing a different icon.

What choosing a browser now means

The comparisons that get written are about speed and appearance. The things that change a working day are less photogenic.

• How many storage areas can be maintained without the upkeep becoming a chore.
• Whether the tools used all day can be kept somewhere other than the strip holding whatever is being read right now.
• How notifications are handled, since that determines how often concentration breaks.
• How much migration will cost, which follows from the engine family.

The first two are the design problem behind a browser that keeps each web app in its own window: every application gets a fixed place with its own session, so identity is implied by location rather than confirmed before each action. What that covers is set out in Features, and the way several identities are arranged is in Workspaces. Products in the same category differ mainly in how far the isolation goes and what it costs, which is the ground of Compared with Wavebox and Compared with Ferdium. The services that can be held this way are listed in Supported apps.

What to change first

Count the day honestly. Separate the pages being read from the applications that stay open, and separate the number of identities in use from the number of storage areas available. If the second list is longer than a handful, a single horizontal tab strip is the wrong container for it, and if identities outnumber storage areas, no arrangement of tabs will fix the resulting mistakes. Both counts point at the same layer, and SpaceDeck is built around that layer rather than around the strip.