The Hidden Browser Quirks That Keep the Web Working (And Why You Should Care)

The Web's Dirty Little Secret

Here's something that might shake your faith in web standards: major browsers ship with domain-specific code that changes how websites render. Not as a hack. Not as a bug. As an intentional feature.

If you're on TikTok, your browser behaves differently than it does on your site. Same for Netflix, Instagram, Amazon Prime Video, and even SeatGuru—the airline seat comparison tool you've probably used once.

This isn't speculation. The code is publicly available. Safari's WebKit engine has a file called Quirks.cpp with thousands of lines of domain-specific interventions. Firefox exposes theirs in an about:compat page where you can actually see and toggle the quirks on and off. Chrome pretends this doesn't happen, which tells you something interesting about market dominance and incentive structures.

Welcome to the Compat Wars

Open Firefox and type about:compat in the address bar. You'll see a list that reads like a hall of fame for broken websites. Each entry is a targeted workaround for a specific domain, complete with custom CSS injections, JavaScript modifications, and user agent string spoofing.

The situation at Safari is even more transparent. Read through Quirks.cpp on GitHub, and you're essentially reading the secret history of how the modern web actually works—not how it's supposed to work, but how it actually works.

Consider Facebook, X (formerly Twitter), and Reddit. The code has a specific comment:

"Facebook, X, and Reddit will naively pause a <video> element that has scrolled out of the viewport, regardless of whether that element is currently in PiP mode."

So Safari detects when you're on these domains and changes how Picture-in-Picture video works. These are massive companies with enormous engineering teams. They could fix their code. Instead, Safari shipped a workaround to two billion users.

There's another comment about SeatGuru:

"FIXME: Remove this quirk if seatguru decides to adjust their site."

Translation: we tried reaching out, they didn't respond, so we hardcoded a fix into our browser engine instead.

The Cascade Effect: How Chrome Breaks Everything

Here's where it gets really interesting—and depressing, from a web standards perspective.

Chrome dominates the browser market. Developers build for Chrome because that's where most users are. Sites work perfectly in Chrome. When bugs appear in Safari or Firefox, users don't blame the websites; they blame the browsers. So they switch to Chrome, reinforcing its dominance. Rinse and repeat.

But the deeper problem is that Chrome's feature decisions become de facto web standards. Chrome ships a feature. Developers adopt it because Chrome has 65% market share. Safari and Firefox either implement the feature themselves (which takes time and resources) or ship domain-specific quirks to paper over the differences.

WebKit's source code includes user agent overrides that make Safari pretend to be Chrome for sites like Amazon's video platform and various streaming services. These sites actively sniff the browser and serve degraded experiences to non-Chrome browsers. So rather than let Safari users suffer, WebKit lies about what browser it is.

Here's the actual code:

auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;

Safari shipping with a fake Chrome user agent string. Firefox does the same thing. When sites refuse to work on non-Chrome browsers, these other engines just pretend to be Chrome and move on.

This creates a feedback loop that's nearly impossible to escape. Developers optimize for Chrome. Non-Chrome users blame their browser. The dominance continues.

Beyond Cosmetics: The Deep Quirks

These aren't just visual tweaks or minor rendering adjustments. Browsers fundamentally alter their behavior based on which domain you're visiting. We're talking about scrolling behavior, touch event handling, viewport calculations, and image MIME type handling.

In just the last few months of commits to WebKit's Quirks.cpp: Zillow's floorplan images weren't centering properly, TikTok was showing "please upgrade your browser" messages, Instagram Reels were resizing erratically during playback, Netflix's UI buttons were dismissing popovers incorrectly, Twitch was pausing Picture-in-Picture videos when you switched tabs, and Amazon Prime Video wasn't working in Safari at all.

Each one got a domain-specific fix. Thousands of lines of code dedicated to compensating for broken implementations on major websites.

What This Means for Your Startup

If you're building a web application, here's the uncomfortable truth: you need to test across browsers, not because you should (you should), but because browsers are increasingly making special exceptions for competitors.

The web platform is becoming less about standards and more about pragmatism. Browsers are becoming application-specific, not just browser-specific. They're shipping patches for broken websites rather than waiting for those websites to fix themselves.

For small teams, this is actually good news—you're unlikely to break things in ways that require browser-level interventions. But as you grow, if you're shipping code that doesn't work properly across Safari, Firefox, and Chrome, you might eventually find yourself on the receiving end of one of these quirks.

More importantly, this illustrates why web standards matter. Chrome's market dominance means Chrome's decisions ripple through the entire ecosystem. What Chrome ships influences what developers build, which influences what Safari and Firefox have to support, which influences what gets tested and maintained.

The Honest Reality

The web isn't a level playing field. Major sites get special treatment baked into browser engines. But this also tells us something about the resilience of the platform—browsers will do whatever it takes to keep the web functional, even if it means shipping thousands of lines of domain-specific code.

It's not elegant. It's not what the standards committees intended. But it's the web we actually have. And understanding that gap between the idealized web and the pragmatic web is crucial if you're building on it.

The next time a site works perfectly in Chrome but breaks in Firefox, you might be encountering the aftermath of this architecture. And if you're building something that needs to work across browsers, the lesson is simple: don't rely on browser sniffing, don't assume Chrome behavior is universal, and test obsessively on real browsers.

The web's hidden quirks are a reminder that we're building on a platform held together by good intentions, clever engineering, and increasingly, domain-specific patches.