Three browser engines power the modern web: Blink (Google Chrome, Microsoft Edge, Opera, Brave and most other Chromium browsers), WebKit (Apple Safari and, historically, every browser on iOS), and Gecko (Mozilla Firefox). Each rendering engine is paired with its own JavaScript engine — Blink with V8, WebKit with JavaScriptCore, Gecko with SpiderMonkey. They all target the same published web standards, but they implement those standards on different timelines, which is why a page can look and behave slightly differently from one browser to the next. Blink dominates by volume: combining Chrome (~65% globally), Edge (~5%), Opera and the rest of the Chromium family puts roughly 70% of the world's browsing on a single engine.
That is the summary an AI overview would give you. What it can't give you is the part that actually saves your afternoon: which engine sits behind each browser, where the real compatibility landmines are, and how to test so that "works on my machine" doesn't mean "broken on every iPhone." That is the rest of this article.
The three engines at a glance
If you remember one table from this page, make it this one. It maps every mainstream browser back to its engine, its JavaScript engine, and the compatibility reality that goes with it.
| Engine | JS engine | Browsers using it | Approx. global share | What to watch for |
|---|---|---|---|---|
| Blink | V8 | Chrome, Edge, Opera, Brave, Vivaldi, Samsung Internet, most Chromium browsers | ~70% (Chrome ~65%, Edge ~5%, Opera ~2%) | Forked from WebKit in 2013; now the de-facto reference. "Works in Chrome" ≈ works across the whole Blink family. |
| WebKit | JavaScriptCore | Safari (macOS + iOS); historically all iOS browsers | ~18% (Safari) | Slowest to adopt some new features; iOS-only quirks that emulators miss. The engine you must test separately. |
| Gecko | SpiderMonkey | Firefox, Tor Browser | ~3% (Firefox) | The last major independent, non-WebKit-lineage engine. Your best "second opinion" for standards-correct behavior. |
Two historical notes explain how the landscape got this lopsided. First, Microsoft Edge originally shipped with its own engine, EdgeHTML, but Microsoft rebuilt Edge on Chromium/Blink in January 2020 — consolidating even more of the market onto Blink. Second, the term "WebKit" is often used loosely; today only Safari and Apple's frameworks use WebKit proper.
What a browser engine actually is
A browser engine is the software inside a browser that turns HTML, CSS, and JavaScript into the page you see and interact with. It has two main parts: a rendering engine that lays out and paints the page, and a JavaScript engine that executes scripts. The web only feels like a single platform because these engines all aim at the same published standards. In practice they implement those standards on different timelines, which is the root cause of nearly every cross-browser surprise.
For developers, IT teams, and anyone supporting a mix of devices, knowing which engine sits behind each browser explains most of those surprises before you even open the debugger.
The iOS reality
For most of the mobile web's history, every browser on iOS was WebKit underneath, regardless of its name. Chrome, Firefox, and Edge on an iPhone were skins over Apple's WebKit, because App Store rules required it. That meant a bug present in iOS Safari appeared in every iOS browser — and it made "test on a real iPhone" non-negotiable.
This is technically changing. The EU's Digital Markets Act (DMA) now requires Apple to allow third-party browser engines on iOS in the EU, and Apple shipped the BrowserEngineKit framework in iOS 17.4 to enable genuine Blink or Gecko builds. In practice, though, adoption has been effectively zero: nearly two years on, no shipping iOS browser uses an alternative engine, because Apple's terms require vendors to build an entirely separate EU-only app and restrict the necessary engine work to developers physically in the EU. For the foreseeable future, treat iOS Safari/WebKit as the engine that virtually every iPhone user actually runs.
Why engine differences matter
The visible symptoms of engine differences are familiar to anyone who has shipped a website:
- Feature support varies. A new CSS property, JavaScript API, or HTML element may land in Blink months before it reaches WebKit or Gecko — or vice versa. Until support converges, the same code can work in one browser and silently fail in another.
- Rendering quirks. Subtle differences in flexbox, grid, fonts, form controls, date pickers, and scrolling behavior can shift a layout by a few pixels or break it entirely.
- JavaScript behavior and performance. V8, JavaScriptCore, and SpiderMonkey are independent implementations. They follow the same ECMAScript spec but differ in performance characteristics and in how quickly they adopt newer language features.
Vendor prefixes (-webkit-, -moz-, -ms-) were once the standard way to opt into experimental features per engine. They are now largely a legacy concern: modern features ship unprefixed, and most remaining prefixes exist only for backward compatibility. You rarely need to write new prefixed code today.
Building for cross-browser compatibility
You do not need to memorize every engine's support matrix. A few disciplined practices cover most cases:
- Check support before you rely on a feature. Resources like caniuse.com and MDN's compatibility tables show which engines support a given API and from which version.
- Use Baseline as a guide. Baseline is a web.dev/MDN initiative that labels features as broadly interoperable once they work across the major engines. Targeting Baseline features is a quick way to stay on safe ground.
- Prefer feature detection over user-agent sniffing. Test for the capability itself (for example,
if ('IntersectionObserver' in window)) rather than guessing from the browser's identity string. User-agent strings are easily spoofed, frequently misread, and a poor proxy for what a browser can actually do. If you do need to inspect one, the tool below breaks a user-agent string into its component parts, and our user agent string glossary entry explains the format.
- Practice progressive enhancement. Start with a baseline that works everywhere, then layer on enhancements for engines that support them. The page stays usable even when an advanced feature is missing.
- Test in real browsers. Emulators and a single "modern browser" assumption are not enough. Differences in WebKit on iOS in particular often only surface on actual devices, so include Safari and Firefox alongside a Chromium browser in your testing.
The security and privacy angle
Engine diversity is not just an aesthetic concern. A web where one engine dominates concentrates risk: a single rendering bug or design decision affects nearly everyone, and standards can drift toward whatever that engine implements rather than what the community agrees on. Maintaining viable alternatives like Gecko helps keep the platform open and resilient.
Update cadence is the more immediate security issue. Browser engines are large attack surfaces, and most are patched on rapid, automatic schedules. Risk concentrates where updates lag — older OS versions pinned to outdated WebKit builds, or embedded webviews inside other apps that may not track the latest engine release. From an IT perspective, keeping browsers and the underlying OS current is one of the highest-value endpoint defenses you can maintain.
Key takeaways
Three engines define the modern web: Blink (Chrome, Edge, and most others, ~70% combined), WebKit (Safari and historically all iOS browsers, ~18%, though the EU's DMA is nominally loosening its iOS lock), and Gecko (Firefox, ~3%). They target the same standards but adopt them at different rates. Build with feature detection and progressive enhancement, verify support with caniuse and Baseline, test in real browsers including Safari and Firefox, and keep every engine patched. Do that and the differences become a manageable detail rather than a source of broken pages.