Why websites break silently in other browsers

The bug report sounds familiar: “The page looks broken on my machine.” The developer opens the page and sees — nothing. Everything in its place. Only the call back clears the matter up: the customer is using Safari on an iPhone, she is using Chrome on the desktop. Between the two lie two rendering engines, several screen widths and a series of silent differences, not one of which has ever produced an error message.

That the same website can look different depending on the browser is not an accident but architecture. At the core of every browser works a rendering engine that translates HTML and CSS into pixels. Three families share practically the entire market today: Blink drives Chrome, Edge and most of the smaller Chromium offshoots, Gecko drives Firefox, WebKit drives Safari — and on the iPhone practically all common browsers still render with WebKit to this day, even when it says Chrome or Firefox on the icon.

These engines are independent implementations of the same web standards. The standards describe what a CSS property is supposed to do — but they leave room for manoeuvre, they are implemented at different speeds, and occasionally two development teams understand the same wording differently. The result is three programs that read the same document and arrive at slightly different images. Mostly the differences are invisibly small. Sometimes not.

The decisive point: these differences stay silent. CSS was deliberately designed to be fault-tolerant. A property a browser does not know is simply ignored — without a warning, without a crash, without an entry in any log. What is a blessing when new techniques are introduced, because old browsers do not answer modern stylesheets with total failure, becomes a trap in everyday use: the page does not break, it merely looks wrong. And nobody finds out as long as nobody looks.

The typical breaking points can be sorted. First there are young CSS features that one engine already handles and another does not yet, or handles differently in the details. Then there are questions of layout interpretation — how Flexbox and Grid deal with minimum widths, line breaks or nested containers, where the specification leaves room for interpretation. And then there are the classics: form elements such as select fields, checkboxes and date inputs, which every browser draws to its own taste and which can be restyled only up to a point.

An example from the first category makes the pattern tangible. The CSS property gap, which governs the spacing between elements, was available early in all engines for Grid layout — in the Flexbox context, however, Safari supported it considerably later than Chrome and Firefox. A navigation bar whose menu items were held apart by Flexbox and gap looked immaculate in two engines; in older Safari versions the items stuck together. No error message, no crash, technically everything worked — the page merely looked cramped and unkempt on a portion of iPhones. The remedy in such cases is a fallback with classic margins; but first you have to know that the difference exists. That is precisely the real hurdle with silent breakages: they do not appear in any error list. They appear only in the image.

On top of that come differences that are not in the stylesheet at all. Fonts are rendered differently on every operating system and come out at different widths; a heading that stays on one line in one environment wraps in another and pushes everything below it downwards. Scrollbars either take space away from the content or lay themselves over it, depending on the system — and thereby change the available width. Viewport units behave differently on mobile devices, depending on how the browser accounts for address bars that appear and disappear.

The second major source of silent breakages is screen widths. Responsive design defines switching points — breakpoints — at which the layout rebuilds itself: the navigation collapses into a menu icon, columns stack on top of one another, spacings shrink. Experience shows that testing is done at the standard widths of common devices. Things break in between: at unusual window sizes, on tablets in landscape, with halved windows on wide desktop monitors.

German-language sites are hit particularly hard by one peculiarity: long compound nouns. Where English gets by with three short words, German offers “Datenschutzgrundverordnung”, its one-word name for the GDPR — a word that refuses to break, juts out of its container or blows a navigation bar apart as soon as space runs short. Translated interfaces that looked immaculate in the English original are therefore among the most reliable candidates for line-break problems.

Even a page that looks correct everywhere today does not stay that way of its own accord, incidentally. Browsers update themselves at short intervals, rendering engines change details of their behaviour — and the website changes its appearance without anyone having deployed a thing. The careful test at launch is therefore a snapshot, not a permanent condition. The same applies in the other direction: every CMS update, every new plugin, every text change can trigger shifts.

Behind all of this lies a basic psychological problem that everyone knows from everyday development: “works on my machine.” Whoever builds a page sees it a hundred times over in their own browser on their own monitor — and unconsciously takes that view to be the truth. Visitors, however, are spread across engines, device classes and window sizes, and none of them reports in of their own accord when something slips. Very few people write an email when a menu overlaps. They simply leave.

All the more valuable, then, is the rare case in which somebody does get in touch — provided the report is worked through methodically. A proven procedure has four steps. First, ask about the environment: which browser, which device, roughly what window width? Without those details every search is guesswork. Second, reproduce it in the appropriate engine, not in a simulation — at a pinch via a screenshot service, if no device with the right engine is to hand; ScanU describes step by step how such a check run proceeds. Third, narrow down which mechanism is affected: does the layout break at a switching point, is a CSS feature missing, does a font come out wider? The answer determines the repair — breakpoint problems are solved by your own stylesheet, missing features need a fallback, font problems often just need more generous containers. And fourth, the step that is most often skipped: after the correction, look at all the engines again. Anyone who checks only the reported spot easily overlooks the fact that the repair has shifted something elsewhere.

The obvious objection at this point would be that browsers' developer tools solved the problem long ago: every modern browser comes with a device mode that simulates the screen sizes of phones and tablets. The objection overlooks what that mode actually does. Anyone who selects the iPhone view in Chrome gets a narrow window with an adjusted resolution and a mobile identifier — but rendering still happens with Blink, Chrome's engine. This simulation does not show the WebKit peculiarities of the real iPhone browser, and no more does it show the Gecko peculiarities of Firefox. For work on breakpoints the device mode is an excellent tool; as evidence of browser compatibility it is useless. An engine cannot be simulated, only swapped.

How do you find breakages that do not report themselves? The traditional route is manual work: a cupboard full of test devices or a browser list that someone clicks through after every change. That works but scales badly — even three browsers times three device classes gives nine views per page, and experience shows that care declines with every repetition. The more systematic route is screenshot services that parallelise this visual inspection. ScanU, for instance, produces screenshots in Chrome, Firefox and Safari in around 30 seconds once a URL has been entered, each in mobile, tablet and desktop views; which device combinations are available is listed in ScanU's feature overview. Instead of opening nine windows one after another, you see a grid of images — and outliers leap out at you.

It gets really interesting in repetition. Services of this kind compare the current state with a stored reference state and mark deviations side by side. The vague question “does the page look good everywhere?” thus turns into the considerably sharper question “has anything changed since the last checked state?” — a question that can be answered even when nobody remembers any more what the page looked like last week.

Here too honesty is part of the deal: screenshots show states, not sequences. What happens on mouse-over, whether a menu opens cleanly, how the page behaves when scrolling or on a slow connection — none of that is captured by a static image. Nor does a rendered browser window replace the feel of real hardware: touch operation, the performance of older devices, the quirks of individual system versions. Before an important launch, reaching for a real phone remains a good idea, and a screenshot does not replace functional tests anyway.

How much effort the topic deserves is not something anyone has to decide in the abstract — your own traffic statistics point the way. They show which browsers, device classes and screen widths actual visitors arrive through, and thus which combinations deserve priority in the test list. Two caveats belong with that, however. First, the statistics measure only who comes — not who does not stay in the first place because of a broken view; a weakly represented engine can therefore also be the consequence of a problem, not merely a sign of low relevance. Second, the shares differ considerably by target group and usage situation: an offering that is read on the sofa in the evening has a different device distribution from a trade portal for the working day. Your own test list should therefore follow your own figures, not general market overviews.

For everyday use a simple routine is often enough: after every change to styles or templates, check the most important pages across all three engine families; after major browser releases, review the estate once; during redesigns, deliberately look at the intermediate widths too, not only the standard formats. Anyone shying away from the effort starts small — ScanU's English-language site introduces the service, whose free tier, with one project and 500 credits a month, is enough for first steps.

The core of the problem remains in place, and that is perhaps the real insight: browsers will continue to be independent programs with their own engines, standards will continue to leave room for manoeuvre, and CSS will continue to stay silent instead of warning. Silent breakages are not a sign of sloppy work but a systemic property of the web. Dealing with them is therefore above all a question of visibility: anyone who regularly looks at their own site through the eyes of all three engines — with whatever tool — takes the sting out of the silence.