Wat is cross-browser compatibiliteit?

Cross-browser compatibiliteit betekent dat je website werkt en er goed uitziet in elke browser waarmee bezoekers langskomen: Chrome, Safari, Edge, Firefox en de varianten daarvan op telefoons.

Het was vroeger een van de vervelendste onderdelen van websitebouw. Dat is het niet meer, omdat vrijwel alle browsers op nog maar drie onderliggende motoren draaien. Wat overblijft is een korte lijst met echte verschillen, en die zitten bijna allemaal aan de kant van Apple.

Wat er onder een browser zit

Een browser bestaat uit een schil en een motor. De schil is wat je ziet: tabbladen, favorieten, instellingen. De motor doet het echte werk, het omzetten van HTML, CSS en JavaScript naar wat er op je scherm staat.

Er zijn er drie over. Blink zit onder Chrome, Edge, Opera, Brave, Vivaldi en Samsung Internet. WebKit zit onder Safari. Gecko zit onder Firefox.

Dat betekent dat testen in Chrome en daarna in Edge je weinig nieuws oplevert, want dat is twee keer dezelfde motor. Testen in Chrome en daarna in Safari wel. Op Samsung-toestellen staat Samsung Internet vaak voorop; dat draait ook op Blink, met eigen instellingen voor advertentieblokkers en donkere modus.

Apps die een webpagina in zichzelf openen, zoals Instagram of LinkedIn, gebruiken een ingebouwd browservenster. Dat is meestal dezelfde motor als de systeembrowser, maar met minder mogelijkheden en soms zonder toegang tot eerder opgeslagen gegevens. Klachten die je niet kunt reproduceren komen vaak daarvandaan.

Op een iPhone is elke browser Safari

Dit is het belangrijkste stukje kennis in dit hele onderwerp. Apple verplichtte browsers op iOS jarenlang om de motor van Safari te gebruiken. Chrome op een iPhone is dus geen Chrome; het is Safari met een andere schil en andere synchronisatie.

Sinds maart 2024 is dat juridisch veranderd. De Europese Digital Markets Act verplichtte Apple om alternatieve browsermotoren in de EU toe te staan, en met iOS 17.4 kwam daar een technische voorziening voor, samen met een keuzescherm waarin gebruikers hun standaardbrowser kiezen.

In de praktijk is er tot nu toe weinig van gekomen. De grote browsers draaien op iPhones nog steeds op WebKit. Blijf er dus van uitgaan dat wat in Safari stuk is, op elke iPhone stuk is.

Er zit nog een addertje aan die kant. Safari wordt bijgewerkt met het besturingssysteem. Iemand met een oudere iPhone of een Mac die geen nieuwe macOS meer krijgt, zit vast op een oudere Safari en kan niet los updaten. Op Windows en Android installeer je wel een nieuwe browser op een oud systeem. Dat maakt de staart van oude Safari-versies langer.

Waarom oude Internet Explorer geen onderwerp meer is

Microsoft heeft de Internet Explorer 11 desktop-app op 15 juni 2022 uitgezet. Wie nog een snelkoppeling heeft, opent tegenwoordig Edge.

Wat er nog bestaat is de IE-modus in Edge, bedoeld voor oude bedrijfssoftware die alleen in Internet Explorer draait. Microsoft heeft toegezegd die modus tot minstens 2029 te ondersteunen. Een beheerder moet daar per adres beleid voor instellen; je bezoekers krijgen dat niet vanzelf.

Praktisch: je hoeft geen rekening meer te houden met Internet Explorer, tenzij je een toepassing bouwt voor een organisatie die daar zelf om vraagt. Alles wat je in oudere artikelen leest over prefixen, conditional comments en shims voor IE kun je overslaan. Ik kom die verouderde adviezen nog steeds tegen in themadocumentatie, dus kijk altijd naar de publicatiedatum voordat je zoiets overneemt.

Waar de verschillen nu nog zitten

Nieuwe mogelijkheden in CSS en JavaScript komen niet op hetzelfde moment in alle browsers beschikbaar. Meestal scheelt het maanden, soms een jaar of meer.

Het beeld dat Safari altijd achterloopt klopt niet helemaal. De selector die kijkt of een element bepaalde kinderen bevat, geschreven als de has-selector, verscheen juist als eerste in Safari, kwam daarna in Chrome en pas eind 2023 in Firefox. Andersom loopt Safari bij andere onderdelen wel achter.

Er zijn twee hulpmiddelen die dit inzichtelijk maken. Op Can I Use en op MDN zie je tegenwoordig een Baseline-aanduiding. Newly available betekent dat iets net in alle grote motoren zit; Widely available betekent dat het er dertig maanden in zit, en dan kun je het zonder terugvaloptie gebruiken. Dat verschil is precies de vraag die je je moet stellen voordat je iets nieuws inzet.

Daarnaast draait sinds 2022 het Interop-project, waarin Apple, Google, Microsoft en Mozilla samen met een paar andere partijen elk jaar afspreken welke verschillen ze wegwerken. De voortgang staat op een openbaar bord. Dat is de reden dat dit onderwerp elk jaar een beetje kleiner wordt.

De klassieke problemen op iOS

Deze vijf kom ik het vaakst tegen, en ze zijn allemaal bekend en oplosbaar.

• Volledige schermhoogte klopt niet. De eenheid vh rekent op een iPhone met de balken weg, dus een blok van 100vh valt deels achter de adresbalk. Sinds 2022 bestaan er eenheden die daar wel rekening mee houden, met dvh voor de veranderende hoogte. Gebruik die.
• Het formulier zoomt in. Staat de letter in een invoerveld kleiner dan 16 pixels, dan zoomt Safari bij het aantikken in en komt je bezoeker scheef op de pagina uit. Zet invoervelden op minimaal 16 pixels.
• Een vast element springt bij het toetsenbord. Een balk die onderaan vastzit, gaat op iOS zwerven zodra het toetsenbord verschijnt. Los het op met een gewone plek in de pagina in plaats van een vaste.
• Hover blijft plakken. Op een aanraakscherm blijft een hover-effect na het tikken staan tot je ergens anders tikt. Zet die effecten binnen een regel die alleen geldt voor apparaten met een muis.
• De inkeping en de thuisbalk. Op toestellen met een inkeping valt inhoud eronder als je de pagina over de volle breedte laat lopen. Daar bestaat een veilige-zone-instelling voor.

Zie je iets vreemds dat je op je laptop niet kunt nabootsen, begin dan bij dit rijtje.

Formulieren en systeemelementen

Keuzelijsten, datumkiezers, bestandsknoppen en schuifregelaars worden door het besturingssysteem getekend, niet door jouw stylesheet. Ze zien er per systeem anders uit en laten zich maar beperkt vormgeven.

De datumkiezer is het duidelijkste voorbeeld. Op iOS krijg je een rollend wiel, op Android een kalender, op een computer weer iets anders. Alle drie werken ze, en alle drie zien ze er anders uit dan je ontwerp.

De verleiding is dan om zo'n element zelf na te bouwen met divs en JavaScript. Doe dat niet zonder goede reden. Een nagebouwde keuzelijst werkt zelden met een toetsenbord, wordt vaak niet voorgelezen door schermlezers en breekt op precies één browser waar je niet test. Een gewone keuzelijst werkt overal.

Wat wel goed werkt: de accentkleur van je site meegeven, zodat vinkjes en schuifregelaars in je huisstijl komen. En invoervelden het juiste type geven, zodat een telefoon meteen het cijfertoetsenbord opent. Meer daarover staat bij het contactformulier.

Let ook op de foutmeldingen van de browser zelf. Die verschijnen in de taal van het systeem, niet in de taal van je site. Dat verklaart waarom je eigen tekst er soms niet staat.

Beeld, video en geluid

Bij afbeeldingen is het rustig geworden. WebP werkt sinds 2020 in alle grote browsers, inclusief Safari. AVIF kwam later; Safari ondersteunt het sinds versie 16.4 uit maart 2023. Wil je het gebruiken zonder risico, dan zet je het in een picture-element met een JPEG of WebP als terugval. Wat die formaten precies doen staat bij webp-afbeeldingen en bij avif-afbeeldingen.

Video is lastiger. Automatisch afspelen met geluid is overal geblokkeerd. Wil je een video als achtergrond, dan moet hij gedempt zijn en moet je het attribuut meegeven dat aangeeft dat hij in de pagina mag spelen in plaats van schermvullend; zonder dat attribuut opent iOS de video in een eigen speler over je hele scherm heen.

Dan de codecs. H.264 werkt overal. AV1 geeft kleinere bestanden en wordt door Chrome en Firefox ondersteund, maar Safari doet het alleen op apparaten met de juiste hardware, dus op nieuwere Apple-chips. Zet je een video zelf op je server, geef dan meerdere bronnen mee met H.264 als terugval. De simpelste weg blijft zware video bij een videodienst neerzetten en die het formaat per apparaat laten regelen.

Eén onbekende functie legt je hele script plat

Bij CSS is een niet-ondersteunde regel vervelend maar zelden fataal: de browser slaat de regel over en de rest blijft staan. Bij JavaScript ligt dat anders. Eén onbekende functie geeft een fout, en afhankelijk van waar die staat stopt de rest van het bestand met werken.

Zo raakt een pagina in één browser volledig van slag terwijl hij elders normaal doet. Je menu klapt niet meer open, je formulier verstuurt niets, je schuifpaneel staat stil. Op je eigen computer merk je er niets van.

Twee gewoontes voorkomen dit. Controleer voordat je een nieuwe functie gebruikt de ondersteuning, en gebruik feature detection: vraag de browser of hij iets kan in plaats van te raden op basis van zijn naam. In CSS doe je dat met een supports-regel.

Kijken naar de user agent, het tekstje waarmee de browser zich voorstelt, was altijd al onbetrouwbaar en is dat nu helemaal. Chrome is die tekst sinds 2022 stapsgewijs gaan versimpelen, zodat er minder over het toestel in staat. Code die daarop leunt gaat op enig moment stuk.

Wat er verder in JavaScript en CSS gebeurt staat bij JavaScript en bij CSS.

Privacy-instellingen verschillen ook, en dat merk je in je cijfers

Browsers verschillen tegenwoordig meer in wat ze blokkeren dan in wat ze kunnen tonen. Dat raakt niet je vormgeving maar je metingen.

Safari wist cookies die door JavaScript zijn gezet na zeven dagen. Firefox houdt cookies per website gescheiden, standaard aan sinds 2022. Beide maken van een terugkerende bezoeker een nieuwe bezoeker, wat je bezoekcijfers opdrijft en je toeschrijving aan een advertentie of nieuwsbrief onbetrouwbaar maakt.

Daar komen advertentieblokkers en inhoudsfilters bovenop, die op de ene browser makkelijker te installeren zijn dan op de andere. Wat je in je statistieken over browserverdeling ziet, is dus zelf al vertekend: de browsers waarin meer geblokkeerd wordt, zijn ondervertegenwoordigd in je eigen cijfers.

Voor A/B-tests is dat verstrekkend, want die houden per bezoeker bij welke variant hij zag. Hoe dat uitpakt staat bij A/B-testen.

Wat je moet ondersteunen

Niet alles. Kijk in je eigen statistieken welke browsers je bezoekers echt gebruiken, en lees dat cijfer met de vertekening hierboven in je achterhoofd.

Voor de meeste Nederlandse sites dekt Chrome, Safari, Edge en Firefox in hun laatste twee versies ruim boven de negentig procent van het verkeer. Samsung Internet is het enige dat daar soms nog serieus bij komt.

Belangrijker dan browserversies zijn schermformaten en aanraakbediening. Daar zitten de echte verschillen in hoe iets aanvoelt: een menu dat met een muis prettig werkt kan met een duim onbruikbaar zijn. Hoe je daarmee omgaat staat bij responsive webdesign.

Spreek voor jezelf een ondergrens af en schrijf hem op: bijvoorbeeld de laatste twee versies van de vier grote browsers, plus iOS vanaf twee versies terug. Dan weet je wanneer je iets wel of niet hoeft te repareren.

Hoe je test zonder apparatenlab

Je hebt geen kast met twintig toestellen nodig. Dit is genoeg voor een gewone bedrijfssite.

• Je eigen telefoon en een geleende. Heb je een iPhone, leen dan een Android van iemand, of andersom. De simulator in je browser doet niet hetzelfde en zegt niets over hoe aanraken voelt.
• Aankoppelen met een kabel. Een iPhone met een kabel aan een Mac laat je in Safari de foutmeldingen van die telefoon lezen, nadat je op de telefoon bij Safari onder geavanceerd de webinspector hebt aangezet. Voor Android doe je hetzelfde vanuit Chrome op je computer.
• Twee motoren op je bureaublad. Chrome en Safari op een Mac, Chrome en Firefox op Windows. Chrome plus Edge is twee keer dezelfde motor en dus geen extra dekking.
• Op 320 pixels breed. Daar breekt het meeste, en die schermen bestaan nog.
• Met alleen een toetsenbord. Kun je met de tabtoets door je hele formulier en zie je onderweg waar je staat.
• Met de foutmeldingen open. Een script dat in één browser stilletjes faalt, legt daar soms je hele pagina plat.

Wil je het automatiseren, dan kun je met Playwright dezelfde klikroute in Chromium, Firefox en WebKit laten aflopen. Dat dekt de drie motoren. Voor wie in veel meer combinaties wil testen bestaan diensten met echte toestellen op afstand, zoals BrowserStack en LambdaTest, maar voor een gewone bedrijfssite is dat niet nodig.

Let op één ding: de snelheidstest van Lighthouse draait in Chromium. Die zegt niets over hoe je site zich in Safari gedraagt.

Hoe je problemen voorkomt tijdens het bouwen

Gebruik standaardonderdelen en verzin geen eigen oplossingen voor dingen die de browser al kan. Een gewone knop werkt overal; een knop die je zelf van een div hebt gemaakt werkt nergens helemaal.

Bouw zo dat het ook werkt als een onderdeel niet meedoet. Laadt een animatie niet, dan hoort je pagina gewoon leesbaar te blijven. Doet een lettertype het niet, dan valt hij terug op een systeemletter zonder dat je tekst wegvalt.

Werk met flexibele indelingen in plaats van vaste breedtes. Het grootste deel van wat mensen browserproblemen noemen is in werkelijkheid een blok met een vaste breedte in pixels, meestal aangezet in een paginabouwer.

Bij WordPress komt daar een eigen risico bij. Elke plug-in voegt zijn eigen JavaScript toe, en die code is niet altijd in Safari getest. Zet een plug-in die je niet gebruikt daarom uit. Hoe je dat beheer aanpakt staat bij het beveiligen van een WordPress-website.

Toegankelijkheid loopt hier doorheen. Schermlezers worden meestal in een vaste combinatie gebruikt, zoals VoiceOver met Safari en NVDA met Firefox. Sinds 28 juni 2025 gelden er bovendien wettelijke toegankelijkheidseisen voor onder meer webwinkels, met een uitzondering voor micro-ondernemingen met minder dan tien mensen en een omzet onder de twee miljoen euro. Wat dat betekent staat bij front-end ontwikkeling.

Wat het kost als het misgaat, en waaraan je het merkt

Meestal is je site niet helemaal kapot. Meestal is het één ding: een knop die op een iPhone niet reageert, een formulier dat in Safari niets verstuurt, een menu dat op Android over de tekst valt.

Dat is precies het vervelende eraan. Jij gebruikt je eigen browser en ziet niets. Ondertussen kan een deel van je bezoekers niets bij je bestellen, en die mensen sturen geen mailtje. Ze gaan weg.

Er is één cijfer waarmee je dit opspoort. Zet in je statistieken je conversiepercentage af tegen de browser. Ligt Safari structureel ver onder Chrome terwijl het bezoek vergelijkbaar is, dan heb je een technisch probleem en geen marketingprobleem. Dat onderscheid scheelt maanden aan verkeerde aandacht.

Een tweede manier is foutmeldingen van bezoekers verzamelen. Er zijn diensten die JavaScript-fouten uit echte bezoeken naar je toe sturen, inclusief browser en versie. Voor een site waar geld doorheen loopt vind ik dat de moeite waard.

Verder blijft het simpel: vijf minuten testen op een echt toestel bij elke oplevering. Dat is precies wat er als eerste sneuvelt bij tijdsdruk.

Veelgestelde vragen over cross-browser compatibiliteit

Wat is cross-browser compatibiliteit?

Cross-browser compatibiliteit betekent dat je website in elke browser werkt en er goed uitziet, dus in Chrome, Safari, Edge, Firefox en de mobiele varianten daarvan.

Het gaat niet om exact hetzelfde beeld tot op de pixel. Het gaat erom dat alle functies werken en dat de pagina overal leesbaar en bedienbaar blijft.

Welke browsers moet ik ondersteunen?

Voor de meeste Nederlandse sites zijn de laatste twee versies van Chrome, Safari, Edge en Firefox voldoende, plus Samsung Internet als je veel Android-bezoek hebt. Daarmee dek je ruim boven de negentig procent.

Kijk het na in je eigen statistieken. Heb je een doelgroep die op oudere apparaten werkt, dan schuift die grens.

Waarom ziet mijn site er anders uit in Safari?

Safari draait op WebKit en de andere grote browsers op Blink of Gecko. Nieuwe mogelijkheden in CSS komen niet op hetzelfde moment in alle motoren beschikbaar, en systeemonderdelen zoals keuzelijsten worden door macOS en iOS zelf getekend.

Kleine verschillen in letterweergave en spatiëring horen erbij. Valt er iets echt weg, controleer dan of je een CSS-eigenschap gebruikt die Safari nog niet kent.

Is Chrome op een iPhone echt anders dan Chrome op een laptop?

Ja. Op een iPhone gebruiken alle browsers de motor van Safari, dus Chrome is daar Safari met een andere schil. Wat in Safari stuk is, is op elke iPhone stuk.

Sinds maart 2024 mag dat in de Europese Unie anders door de Digital Markets Act, en met iOS 17.4 kwam daar een voorziening voor. In de praktijk draaien de grote browsers op iOS nog steeds op WebKit.

Moet ik nog rekening houden met Internet Explorer?

Nee. Microsoft heeft de Internet Explorer 11 desktop-app op 15 juni 2022 uitgezet en verwijst gebruikers door naar Edge.

Er bestaat nog een IE-modus in Edge voor oude bedrijfssoftware, die Microsoft tot minstens 2029 ondersteunt. Dat is iets voor interne toepassingen, niet voor een publieke website.

Hoe test ik mijn site op een iPhone als ik er geen heb?

Leen er een. Vijf minuten op een echt toestel zegt meer dan een uur in een simulator, vooral over aanraken en over de hoogte van je pagina.

Lukt dat niet, dan zijn er diensten met echte toestellen op afstand, zoals BrowserStack en LambdaTest. De ingebouwde simulator in Chrome verandert alleen het schermformaat en gebruikt gewoon Blink, dus die vindt Safari-problemen niet.

Waarom zoomt mijn formulier in op een iPhone?

Omdat de lettergrootte in het invoerveld kleiner is dan 16 pixels. Safari zoomt dan bij het aantikken automatisch in, zodat de tekst leesbaar wordt.

Zet invoervelden op minimaal 16 pixels. Het uitschakelen van zoomen via de viewport-instelling lost het ook op, maar dat is slecht voor mensen die zelf willen inzoomen.

Waarom start mijn video niet vanzelf op mobiel?

Automatisch afspelen met geluid is in alle browsers geblokkeerd. Een video mag alleen vanzelf starten als hij gedempt is.

Op iOS heb je daarnaast het attribuut nodig dat aangeeft dat de video binnen de pagina mag spelen. Zonder dat attribuut opent iOS hem schermvullend in een eigen speler.

Wat betekent Baseline op Can I Use en MDN?

Baseline geeft aan of een webtechniek in alle grote browsermotoren zit. Newly available betekent dat het er net in zit, Widely available dat het er dertig maanden in zit.

Voor een gewone bedrijfssite is Widely available de veilige grens. Bij Newly available kun je het gebruiken, maar zorg dan dat de pagina zonder die techniek ook werkt.

Hoe weet ik welke browsers mijn bezoekers gebruiken?

In Google Analytics of een ander statistiekenpakket vind je een overzicht per browser en per besturingssysteem. Kijk daar voordat je besluit wat je ondersteunt.

Lees dat cijfer wel met een korrel zout. Bezoekers die je meting blokkeren of de cookiemelding weigeren tellen niet mee, en dat zijn niet toevallig de browsers waarin blokkeren makkelijk is.

Waarom klopt 100vh niet op een telefoon?

De eenheid vh rekent op mobiel met het scherm zonder adresbalk en knoppenbalk. Zodra die balken in beeld zijn, valt een deel van je blok eronder weg.

Gebruik in plaats daarvan dvh, de eenheid die met de veranderende hoogte meebeweegt. Die werkt sinds 2022 in alle grote browsers.

Moet ik nog polyfills en autoprefixer gebruiken?

Veel minder dan vroeger. De meeste CSS-prefixen zijn overbodig sinds Internet Explorer weg is, en moderne JavaScript werkt in alle huidige browsers.

Er zijn uitzonderingen bij heel nieuwe technieken. Controleer per geval de Baseline-aanduiding in plaats van standaard een pakket met terugvalcode mee te leveren dat je site alleen maar zwaarder maakt.

Wat is Interop?

Interop is een samenwerking waarin Apple, Google, Microsoft en Mozilla elk jaar afspreken welke verschillen tussen browsers ze wegwerken. De voortgang staat op een openbaar bord met testresultaten.

Het loopt sinds 2022. Kom je iets tegen dat in de ene browser wel werkt en in de andere niet, dan is de kans groot dat het al op die lijst staat.

Mijn menu werkt niet op Android, waar begin ik?

Sluit je telefoon met een kabel aan op je computer en open de foutmeldingen via Chrome. Negen van de tien keer staat daar een JavaScript-fout die de rest van het bestand stillegt.

Zie je geen fout, kijk dan naar overlappende lagen en naar vaste breedtes in je menu. Een blok dat op een breed scherm past, duwt op 320 pixels de rest van de pagina weg.