Is Chrome the New Internet Explorer? How Chromium Dominance Affects Web Standards

Mar 12, 2026

Purpose

Developers often say “Safari is the new Internet Explorer.” But when I look at the data, Chrome deserves this label more.

Chrome dominates browser market share. Chromium engine powers most browsers. Google shapes web standards through Chrome’s implementation power.

Let me explain why this matters.

The Chromium Engine Monopoly

When I talk about browser dominance, I mean engine dominance—not just browser share.

┌─────────────────────────────────────────────────────────┐
│ Chromium Engine (Chrome, Edge, Brave, Opera, Vivaldi)  │
│ ████████████████████████████████████████ ~79%           │
├─────────────────────────────────────────────────────────┤
│ WebKit (Safari)                                         │
│ █████████ ~18%                                          │
├─────────────────────────────────────────────────────────┤
│ Gecko (Firefox)                                         │
│ ██ ~3%                                                  │
└─────────────────────────────────────────────────────────┘

Almost 80% of browsers use Chromium. This is the real monopoly.

What This Means

When I test websites, I usually test in Chrome. But Chrome, Edge, Brave, and Opera all use the same engine. They render pages identically.

Testing Chrome = Testing Edge = Testing Brave = Testing Opera
They all use Chromium engine

I’m not testing across different engines. I’m testing one engine with different UIs.

Chrome vs IE: The Historical Parallel

How does Chrome compare to IE6’s dominance?

How IE Dominated

Microsoft bundled IE with Windows
IE achieved ~95% market share by 2001
Microsoft stopped developing IE
IE forced developers to code for its quirks
“Best viewed in IE” badges became common

How Chrome Dominates

Google built a superior product
Chrome achieved ~65% browser share
Google continues aggressive innovation
Chrome pushes features before standardization
Chrome becomes the de facto standard

The pattern is similar, but Google learned from Microsoft’s mistakes.

The “Chrome is the New IE, But in Reverse” Pattern

Here’s the key insight: Microsoft ignored standards. Google becomes the standard.

IE6 Approach:
  Ignore web standards → Force developers to use IE-specific code → Lock in users

Chrome Approach:
  Ship features fast → Features become de facto standards → Other browsers follow

Google doesn’t ignore standards. Google shapes standards by implementing features first.

Example: Web Components

// Chrome shipped Web Components before standardization
class MyElement extends HTMLElement {
  connectedCallback() {
    this.innerHTML = '<p>Custom element</p>';
  }
}
customElements.define('my-element', MyElement);

// Other browsers had to catch up
// Now it's a standard

Chrome implemented first. The feature became a standard because Chrome did it.

Example: File System Access API

// Chrome 86+ only
if ('showOpenFilePicker' in window) {
  const [fileHandle] = await window.showOpenFilePicker();
}

// Safari and Firefox don't support this
// Developers must provide fallbacks

Some APIs remain Chrome-specific. This creates “works best in Chrome” pressure.

Why This Matters for Developers

Testing False Confidence

When I test in Chrome, I feel confident. But I’m only testing one rendering engine.

Testing Chrome + Edge = Testing Chromium twice
I'm missing WebKit and Gecko entirely

Chrome-Only Features

Some features only work in Chromium browsers:

// File System Access API
if ('showOpenFilePicker' in window) {
  // Chrome/Edge only
  useNativeFileAccess();
} else {
  // Safari, Firefox fallback
  useTraditionalFileInput();
}

// Web Serial API
if ('serial' in navigator) {
  // Chrome only
  connectToSerialDevices();
}

The “Works in Chrome” Problem

Stakeholders test in Chrome. When something works in Chrome but not Safari, they blame Safari—not the non-standard code.

Product Manager: "It works in Chrome, why doesn't it work in Safari?"
Developer: "Because we used a Chrome-specific feature..."
Product Manager: "So fix Safari"

This pressure pushes developers toward Chrome-only implementations.

The Monoculture Risk

Single-engine dominance creates risks:

1. Reduced Innovation

When one engine dominates, innovation happens at that engine’s pace.

Chromium decides: "We're not implementing this feature"
→ Feature doesn't get widely adopted
→ Even if Safari/Firefox implement it
→ Developers can't use it (must support Chromium)

2. Standardization Bypass

Google can ship features before standardization:

/* Chrome shipped container queries first */
@container (min-width: 400px) {
  .card {
    /* Works in Chrome 105+, Safari 16+, Firefox 110+ */
  }
}

/* During the gap, Chrome-only code was common */

3. Web Diversity Loss

With Chromium at 79%, web diversity shrinks:

2005: IE, Firefox, Safari, Opera (diverse engines)
2010: Chrome joins, competition increases
2024: Chromium dominates, diversity decreases

What I Can Do

Test Across Engines, Not Browsers

I make sure to test in:

Chromium (Chrome)
WebKit (Safari)
Gecko (Firefox)

Chrome   → Chromium engine
Safari   → WebKit engine
Firefox  → Gecko engine

This is true cross-engine testing

Use Feature Detection

Instead of browser sniffing:

if ('feature' in window) {
  // Use feature
} else {
  // Fallback
}

Advocate for Standards

When stakeholders push for Chrome-only features, I explain the implications:

"This feature works in Chrome only.
Safari and Firefox users will see a fallback.
Is this acceptable for our users?"

Summary

In this post, I explained why Chrome’s dominance mirrors IE’s market position more than Safari’s. The key points are:

Chromium engine powers ~79% of browsers
Google shapes standards by implementing first, unlike IE6 which ignored standards
Single-engine dominance risks web monoculture

The “Safari is the new IE” label misses the real concern: Chromium’s engine monopoly. When one engine controls 79% of the web, we lose the diversity that drives web standards forward.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!