There are more browsers on the market than at any point in the last decade and fewer browser engines than at almost any point in the web’s history. Three engines render every page your visitors see. Blink, which Google develops inside Chromium. Gecko, which Mozilla develops for Firefox. WebKit, which Apple develops for Safari and which every browser on iOS is still required to use. Everything else, the tab strips, the sidebars, the vertical tabs, the AI assistants, the split views, sits on top of one of those three.
That distinction is the most useful thing an agency, a CMS developer, or a small publisher can hold onto, because it turns an unmanageable question ("which browsers do we support?") into a manageable one ("which engines do we support, and where do the browsers on top of them behave differently?"). The answer to the first question changes every few months. The answer to the second has been stable for years.
This is the layer underneath the one we mapped in the 2026 agentic browser landscape. That piece covered what the agents living inside browsers do. This one covers what every one of them is actually rendering with.
This piece covers what a browser engine is and why the count settled at three, the current state of each engine and the browsers that ship it, the new engines people keep asking about, the release cadence change that landed at Chrome and Firefox this month, what each browser blocks by default, where extension platforms have now permanently diverged, what market share figures do and do not tell you, and the test matrix that falls out of all of it.
The short version is this. You have three engines and about four practical test targets: current Chromium stable, current Firefox, current Safari on macOS, and Safari on a real iOS device. That covers close to everything. The differences that will actually cost you a support ticket are not rendering differences between Chrome and Brave, because there mostly are not any. They are default privacy behavior, extension availability, and the fact that iOS is a single engine no matter which icon the user taps. Two things changed in the last two weeks that make the matrix harder to pin down: Chrome and Firefox both moved to a two-week major release cycle, and Chrome finished removing the last Manifest V2 extensions from its store. Neither changes what you test. Both change how fast your "supported versions" table goes stale.
What browser engines are, and why there are only three
A browser engine is the part of a browser that turns markup, styles, and scripts into pixels and events. It parses HTML into a DOM, resolves CSS, runs layout and paint, handles networking and security boundaries, and hosts a JavaScript engine. The browser wrapped around it supplies the interface, the sync, the profile management, the extension host, and increasingly the AI features.
Building one from scratch is a decade-scale project, which is why the field consolidated. The current three:
Blink is developed by Google as part of Chromium and shipped in Chrome, Microsoft Edge, Brave, Opera, Vivaldi, Arc, Dia, Perplexity Comet, and Samsung Internet, among others. Blink is not versioned independently of Chromium, so there is no meaningful "Blink 152" separate from Chromium 152. When you read that a browser is "on Chromium 152," that is its Blink version.
Gecko is developed by Mozilla and ships in Firefox and in Tor Browser, which tracks Firefox’s Extended Support Release rather than the main channel. Gecko’s version is Firefox’s version.
WebKit is developed by Apple, ships in Safari, and is required in every browser on iOS and iPadOS. Chrome on iPhone is WebKit. Firefox on iPhone is WebKit. Brave on iPhone is WebKit. This is the single most important fact in this article for anyone doing mobile testing.
Two other browser engines are worth naming so you can dismiss them accurately rather than vaguely. Neither renders meaningful production traffic today.
Blink: Chrome and everything downstream of it
Chrome 152 held the stable channel through the first week of September 2026, at 152.0.7977.75 and .76, following a security update on September 1 that carried 26 fixes. Chrome 152’s feature release landed on August 25, and Chrome 153 was scheduled to take over on September 8 as the first release on the new cadence.
The developer-facing additions in 152 are the usual mix of CSS and platform work: relative alpha colors, CSSPseudoElement support for ::backdrop, ::scroll-marker and ::view-transition, a window-drag CSS property, a CPU Performance API, WebGPU subgroup size control, and progressive web app sub apps. Chrome 153 continues in that vein with overflow accepting scrollable and clip together, scroll-axis-lock, iterator helpers including Joint Iteration, and a rewrite of Chrome’s XML parsing into a memory-safe Rust implementation.
The engine matters less here than the ecosystem sitting on it. In early September 2026:
- Brave shipped 1.94.119 on September 2, built on Chromium 152.0.7977.76.
- Vivaldi shipped its 8.2 minor update in the first days of September on Chromium 152.0.7977.112.
- Edge shipped 152.0.4191.66 on September 4, on its own 152 line.
- Opera 135 landed on August 20 and trails on the previous Chromium major.
The practical read: the Chromium forks track within one or two majors of upstream, and the lag is the thing worth testing, not the brand. If a feature landed in Chromium 152, assume Brave and Vivaldi have it within days and Opera within a few weeks. If it landed in 153, assume the forks do not have it yet.
Arc deserves a specific note, because agencies keep getting asked about it. The Browser Company was acquired by Atlassian, and Arc’s own site now carries a line that is more precise than most of the coverage of it: "Arc receives Chromium updates only." The site directs users to Dia, which it calls the next evolution of Arc, "for active security patches and enterprise-grade protection." Arc is not dead and it is not abandoned in the sense of no longer launching. It is getting upstream Chromium security work and nothing Arc-specific on top. That is a defensible thing to tell a client, and it is more accurate than "Arc is discontinued."
Gecko: Firefox, Tor Browser, and the funding line underneath
Firefox 155 shipped on September 1, 2026, with 155.0.1 following on September 4 to fix an unresponsiveness bug on pages that combine CSS blur with backdrop filters.
Firefox 155 is a genuinely substantial platform release. attr() became usable in any CSS property with type and fallback values, which is the change most likely to show up in your stylesheets. New progress() and alpha() CSS functions landed. font-width replaced font-stretch. On the JavaScript side, Promise.allKeyed() and Promise.allSettledKeyed() arrived, along with WebAssembly wide arithmetic. Failed module loads are no longer cached as failures, which quietly fixes a category of flaky-import bug.
The attr() addition is worth flagging for a reason beyond the feature itself: attr() is one of the Interop 2026 focus areas, alongside anchor positioning, container style queries, dialogs and popovers, scroll-driven animations, and view transitions. Interop is the annual cross-vendor effort run by Apple, Google, Igalia, Microsoft, and Mozilla to close gaps on a shortlist of features. If you want a defensible answer to "is this safe to use yet," the Interop focus list and Baseline are better inputs than any individual browser’s version number.
Firefox also now shows a count of blocked trackers directly in the address bar, which is a small change with a real consequence: your users can now see, without opening anything, how many third-party requests your pages make.
Mozilla’s funding concentration is the structural fact underneath Gecko, and it is routinely misquoted, so here is the precise version. Mozilla’s audited consolidated financial statements for the year ended December 31, 2024 state: "Approximately 86% and 85% of Mozilla’s revenues from customers with contracts were derived from one customer for the years ended December 31, 2024 and 2023, respectively."
Two precision notes. The denominator is revenues from customers with contracts, not total revenue. Total 2024 revenue was $680.4 million and royalty revenue was $498.2 million, so 86% of total revenue would exceed the entire royalty line. And the audited statement says "one customer" without naming it. Every credible outlet identifies that customer as the Google search default, but that identification is reporting, not something the filing says. Quote the filing as the filing puts it.
Tor Browser is the other Gecko consumer, and it does not track Firefox’s main channel. Tor Browser 15.0.21 shipped on September 1, built on Firefox 140.15 ESR, backporting Firefox 155’s security patches onto a base roughly fifteen releases older. If Tor or the Firefox ESR channel matters to your audience, "we tested Firefox" does not cover it. That is a separate target with a different feature floor.
WebKit: Safari, and every browser on iOS
Safari 26.6.1 shipped on August 18, 2026 for macOS Sonoma and Sequoia with seventeen WebKit security fixes. The last feature release, Safari 26.6 on July 27, was deliberately a consolidation release. WebKit described the work as polishing how features fit together and resolving issues, and the main platform addition was compileOptions for WebAssembly.compileStreaming() and instantiateStreaming(), so that JavaScript String Builtins no longer force a non-streaming compile path.
Safari 27 is in beta and has not shipped as of this writing. It is a large release: 58 new features, 525 bug fixes, and four deprecations. The headline items for front-end work are a customizable <select> element that preserves native accessibility, sizes="auto" for responsive images, transform-aware anchor positioning, the :heading pseudo-class, the stretch keyword, revert-rule, a complete rewrite of the ES module loader that enables spec-correct top-level await, WebAssembly JSPI, scroll anchoring, subpixel inline layout, and Service Worker static routing. It ships with the next major iOS and macOS releases, expected in late September 2026.
Safari also remains the one holdout on release cadence, on roughly annual majors with point releases between them, while Chrome, Firefox, Edge, and Tor Browser have all moved to two weeks.
The iOS situation is the part worth getting exactly right, because it is widely reported in a way that overstates what has happened.
Apple has opened alternative browser engines to developers in two jurisdictions. The European Union came first, and Japan followed in iOS 26.2 under a separate regime. Apple’s own documentation for the Japanese entitlement reads: "In iOS 26.2 and later, browser engines other than WebKit can be used in two types of apps for users in Japan," split between a Web Browser Engine Entitlement for standalone browsers and an Embedded Browser Engine Entitlement for in-app browsing.
The entitlement carries real product requirements. An engine must pass 90% of Web Platform Tests and 80% of Test262. It must block third-party cookies by default unless the user opts in. It must partition storage and state per top-level site. It must ship mitigations for actively exploited vulnerabilities on a roughly 30-day clock for the simplest classes. And the resulting build can be distributed only in the permitted jurisdiction.
No browser vendor has actually shipped a non-WebKit engine on iOS anywhere in the world. The Register put it plainly in June 2026: "Yet more than two years later, no browser maker has launched an alternative browser." We found no evidence that anything has shipped in the months since.
The reason is commercial rather than technical, and The Register named it: a Blink-based Edge on iOS would have to be a separate app from the WebKit-based Edge, which would leave Microsoft to reacquire its entire iOS user base from zero, in one country. Microsoft’s own prototype measured a real gain, scoring 49.27 against Safari’s 38.3 on Speedometer 3.1, about 28.6% faster. That gain has not been enough to justify shipping a jurisdiction-specific app with no users.
For a testing matrix, this means one thing and it has not changed: on iOS, you are testing WebKit, whatever browser your analytics reports.
The new browser engines, and what they are actually for
Two projects come up in every conversation about browser diversity. Both are real. Neither is a target you need to test in 2026.
Ladybird is a genuinely new engine, written from scratch rather than forked, with C++ origins in SerenityOS and an incremental port to Rust underway. It is run by a 501(c)(3) funded by donations and sponsorship, with Platinum sponsors including FUTO, Shopify, and Cloudflare. Progress through 2026 has been steep on benchmarks: Speedometer 2 moved from 47 to 64 over the summer, Speedometer 3 from 2.5 to 3.9, and StyleBench from 3.5 to 83. An alpha is targeted for 2026 on Linux and macOS, with remaining blockers listed as crash reporting, signed builds, auto-update, and a download platform. The project is candid about what an alpha means: "the engine will not be finished when the alpha starts. That’s what the alpha is for."
Servo is a Rust engine that now ships monthly and is published on crates.io as an embeddable library rather than a consumer browser. The project has said it does not plan to publish its demo browser, servoshell, to crates.io. Servo’s trajectory is toward being something you embed in an application, not something your visitors browse with.
Flow, from Ekioh, is a proprietary engine paired with Mozilla’s SpiderMonkey for JavaScript, aimed at embedded and low-power targets such as set-top boxes. It has no desktop consumer plans.
The honest summary: the two credible new engines are aiming at developer alpha and at embedding respectively. Neither changes a 2026 test matrix, and anyone telling you otherwise is selling optimism.
Chrome and Firefox both moved to two-week releases this month
This is the change most likely to break something in your process rather than in your code.
Google announced on March 3, 2026 that Chrome would move from a four-week to a two-week release cycle starting in September, beginning with Chrome 153 on September 8. Chrome’s own beta notes for 153 say it directly: "Chrome 153 is the first Chrome release of the new two-week release cycle."
Mozilla moved at the same time but framed it differently. The dev-platform announcement calls it "an experiment," and adds that "Work that is not ready should not be rushed, and features can still take the time they need to bake." Firefox 155 was pulled forward from September 15 to September 1 to start it, on desktop and Android.
Edge was already there. Its release notes for 152.0.4191.53 on August 27 list a two-week release cadence as a shipped change. Tor Browser and Tails are following Firefox, with the Tails project noting that Firefox is moving to a two-week cadence and that Tor Browser and Tails are doing the same.
So four of the five major release trains are now on a fortnight. Safari is the exception.
What this actually costs you:
- Version-pinned support tables go stale twice as fast. A client contract that names "Chrome 148 and later" now describes a much older floor than it did in the spring.
- CI browser matrices need a floating target. Pinning an exact Chromium build in a test container is now a maintenance job rather than a set-and-forget.
- Bug reports need better version capture. "Latest Chrome" was always a weak field in a support form. It is weaker now.
The fix is to stop describing support by version number and start describing it by capability. Baseline and the Interop focus list give you a vocabulary for that. "We support browsers that implement Baseline Widely Available features" survives a cadence change. "We support Chrome 148+" does not.
What each browser blocks by default
This is where the browsers on top of the same engine genuinely diverge, and it is the difference most likely to affect a publisher’s analytics and a developer’s third-party integrations.
Chrome does not block third-party cookies by default, and has formally said it will not. Privacy Sandbox was retired on October 17, 2025, when Google announced it was retiring ten technologies including Topics, Protected Audience, Attribution Reporting, Private Aggregation, and IP Protection, citing ecosystem feedback about expected value and low adoption. Google’s statement on what replaces it is a statement that nothing does: "Chrome will maintain our current approach to offering users third-party cookie choice in Chrome."
What survived is the part that matters for building things. Google’s status page continues to list Storage and Network State Partitioning, CHIPS (partitioned cookies), the Storage Access API, FedCM, Private State Tokens, bounce tracking mitigations, and User-Agent Client Hints as supported. The through-line is partitioning rather than deprecation. If you are building anything that needs cross-site state in 2026, CHIPS and the Storage Access API are the durable tools, and they work across engines.
Firefox uses Enhanced Tracking Protection. In Standard mode, the default, it blocks social media trackers, cross-site tracking cookies, cryptominers, and fingerprinters, and blocks tracking content in Private Windows only. Total Cookie Protection is on by default in Standard, which confines cookies to the site that set them rather than blocking them outright. Strict mode extends blocking to all cross-site cookies and to tracking content in all windows, and is the mode that breaks sites.
Safari blocks third-party cookies by default and has for years, with Intelligent Tracking Prevention doing on-device classification and partitioned or ephemeral storage on top.
Brave blocks by default through Shields: most ads and their trackers, cookies other than from sites you actually visit, fingerprinting surface reduction, HTTPS upgrades, and known malicious sites. Shields are native to the browser rather than an extension, which is why Brave was able to say that Manifest V3 "will not weaken Brave Shields in any way" and be correct.
The clean framing for a client conversation: Safari and Brave block third-party cookies by default, Firefox isolates them by default and blocks them in Strict, and Chrome does neither and has now said on the record that it will not. That is a four-way split in default behavior, and it is the reason your analytics numbers differ by browser in ways that have nothing to do with your users.
Extensions are where the engines now permanently diverge
Until this year, extension support was a transitional story: everyone was moving to Manifest V3 at different speeds. That stopped being true on August 31, 2026, when Chrome removed the last Manifest V2 extensions from the Chrome Web Store. Google’s own deprecation timeline records it plainly: "All remaining Manifest V2 extensions are removed from the Chrome Web Store."
We covered what that date did and did not change in the Manifest V2 removal, and the short version bears repeating here because it is widely misreported: MV2 extensions stopped executing in Chrome in July 2025. What ended on August 31 was supply, not execution. Copies still installed on Chrome 138 or earlier keep running but cannot update or be reinstalled.
What matters for this piece is that the positions are now settled rather than in motion:
- Chrome has no Manifest V2 at all, in the store or in the browser.
- Firefox keeps both. Mozilla’s stated position is that it "will continue supporting both blockingWebRequest and declarativeNetRequest," which is the technical reason uBlock Origin still works there in its full form.
- Brave self-hosts a small set of MV2 extensions on its own servers, reachable at
brave://settings/extensions/v2, including uBlock Origin, AdGuard AdBlocker, NoScript, and uMatrix. Brave describes this as best-effort and says it will withdraw support as those extensions go stale. - Edge is still mid-transition. Microsoft’s own documentation puts enterprise deprecation in early 2027 with the cutoff for accepting MV2 updates still unstated, while press reporting has described a consumer end-of-2026 target. The sources disagree; Microsoft’s documentation is the one to cite.
The consequence for agencies is concrete. If a client’s workflow depends on a specific extension, the browser choice is now load-bearing in a way it was not two years ago, and "just use Chrome" may be the wrong instruction for the first time in a decade.
Market share, and what the numbers do not say
StatCounter’s figures for August 2026, worldwide:
| Browser | Desktop | Mobile | Combined |
|---|---|---|---|
| Chrome | 73.28% | 66.17% | 69.72% |
| Safari | 5.24% | 25.87% | 15.58% |
| Edge | 10.46% | n/a | 5.41% |
| Firefox | 5.31% | 0.75% | 3.02% |
| Samsung Internet | 1.53% | 2.52% | 2.02% |
| Opera | 1.99% | 1.92% | 1.95% |
Read those with the caveats StatCounter itself publishes. The sample is page views from over a million member sites, not unique users, so a heavy user is counted many times. No weighting is applied, so the sample inherits the geography and demographics of member sites. Individual site statistics can skew by the kind of person who visits that site. Figures remain revisable for 45 days after publication, which means the August numbers above are still inside their revision window. Other panels disagree with StatCounter by a point or more, so cite one source and name it rather than blending.
The arithmetic worth doing yourself: on desktop, Chrome plus Edge plus Opera plus Samsung Internet comes to roughly 87% Blink, before you count Brave, Vivaldi, Arc, and Comet, which fall into "Other." Firefox is the only non-Chromium desktop entry above 5% besides Safari.
Which is the number that makes the point of this article. Browser diversity in 2026 is mostly interface diversity. Diversity among browser engines is three, and on desktop it is heavily weighted to one.
What a small team actually has to test
Here is the matrix that falls out of everything above.
Test on four targets:
- Current Chromium stable. Covers Chrome, Edge, Brave, Opera, Vivaldi, Arc, Dia, Comet, and Samsung Internet for rendering and JavaScript behavior. The forks track within one or two majors.
- Current Firefox. The only mainstream Gecko target on the main channel.
- Current Safari on macOS. The only way to catch WebKit-specific layout and API gaps on desktop.
- Safari on a real iOS device. Not a desktop emulator, and not "Chrome on iPhone," which is the same engine with a different chrome around it.
Add a fifth target only if your audience warrants it: Firefox ESR, if you serve enterprise or institutional users, or Tor Browser, which currently sits on Firefox 140 ESR and therefore lags the main channel by roughly fifteen releases.
Test separately, per browser rather than per engine, for:
- Default privacy behavior. Third-party cookies, storage partitioning, and tracker blocking differ by browser on the same engine. Brave on Chromium behaves nothing like Chrome on Chromium for anything involving third-party requests.
- Extension-dependent workflows. Now genuinely divergent, and permanently so.
- Chromium fork lag. If you ship something that landed in the newest Chromium major, check Opera and the slower forks before you rely on it.
Stop testing by version number. With four of the five release trains on a fortnight, a version-pinned support statement decays faster than the contract it appears in. Describe support in terms of Baseline and the Interop focus areas, and your statement survives the cadence change.
Frequently Asked Questions
How many browser engines are there in 2026? Three that matter for production traffic: Blink (Chromium), Gecko (Firefox), and WebKit (Safari and all of iOS). Ladybird, Servo, and Flow exist and are real projects, but none of them renders meaningful production traffic today.
Is Chrome on iPhone actually Chrome? It is Chrome’s interface, sync, and features wrapped around WebKit. Apple requires WebKit for browsers on iOS. Rendering, JavaScript behavior, and web platform feature support come from Safari’s engine, not from Blink.
Has any browser shipped a non-WebKit engine on iOS yet? No. Apple has opened alternative browser engine entitlements in the European Union and, since iOS 26.2, in Japan, with requirements including passing 90% of Web Platform Tests and 80% of Test262. As of September 2026 no vendor has shipped one anywhere. The blocker is commercial: a separate app, distributable in one jurisdiction, starting from zero users.
Do I need to test Brave, Vivaldi, and Opera separately? For rendering and JavaScript, generally no. They track Chromium within one or two majors. For anything involving third-party requests, cookies, or extensions, yes, because their default blocking behavior differs substantially from Chrome’s on the same engine.
What changed with Chrome and Firefox release cadence? Both moved to two-week major releases in September 2026. Chrome began with version 153 on September 8, following an announcement in March. Firefox began with version 155 on September 1 and describes the change as an experiment. Edge was already on a two-week cadence, and Tor Browser and Tails are following Firefox. Safari remains on roughly annual majors.
Does Chrome still support third-party cookies? Yes, by default. Google retired the Privacy Sandbox technologies on October 17, 2025, and stated it would maintain its current approach of offering users third-party cookie choice. Storage partitioning, CHIPS, and the Storage Access API survived and are the durable tools for cross-site state.
What is the difference between Firefox Standard and Strict tracking protection? Standard, the default, blocks social media trackers, cross-site tracking cookies, cryptominers, and fingerprinters, confines cookies to the site that set them, and blocks tracking content only in Private Windows. Strict extends blocking to all cross-site cookies and to tracking content in every window, and is the mode most likely to break sites.
Can uBlock Origin still run in its full form? In Firefox, yes, because Mozilla continues to support blocking webRequest alongside declarativeNetRequest. In Brave, a self-hosted Manifest V2 copy is available at brave://settings/extensions/v2 on a best-effort basis. In Chrome, no. In Edge, the transition is still underway with dates that differ between Microsoft’s documentation and press reporting.
Is Arc discontinued? Not exactly, and the precise version is more useful. Arc’s own site says it "receives Chromium updates only" and points users to Dia for active security patches. Arc still gets upstream Chromium security fixes; it no longer gets Arc-specific development.
Should I be tracking Ladybird? As an interested observer, yes. As a test target, not in 2026. Its alpha is targeted for this year on Linux and macOS, and the project is explicit that the engine will not be finished when the alpha begins.
Do agentic browsers change any of this? Not at the engine level. Atlas, Comet, Dia, and the assistants built into Chrome and Edge are interface and orchestration layers on top of Blink, so they render what Chromium renders. They do change your security posture rather than your test matrix, which we covered separately in agentic browser security.
Which browser do I recommend to a client who asks? That depends on what they need rather than on a ranking, which is why this article does not have one. If the answer hinges on ad blocking or extension availability, the browser choice matters more than it used to. If it hinges on rendering, it barely matters at all, because roughly nine in ten desktop page views already run on the same engine.
How should I write a browser support statement now? In terms of capability rather than version. Baseline and the Interop 2026 focus areas give you language that survives a two-week release cadence. A statement naming specific version numbers will be describing an old floor within a couple of months.
