Was die Seite macht
Beim Öffnen der Seite führt ein Skript rund 60 kleine Prüfungen in deinem aktuellen Browser aus und führt jede Funktion als unterstützt oder nicht unterstützt auf. Die Ergebnisse sind gruppiert nach JavaScript-Sprachfunktionen, CSS, Grafik, Medien und Codecs, Speicher, Netzwerk, Geräte-APIs, Sicherheit und Oberfläche; ganz oben steht in einer Zusammenfassung, wie viele Funktionen unterstützt werden.
Jede Prüfung ist eine Frage, die der Browser beantworten kann, ohne sichtbar etwas zu tun. Bei JavaScript heißt das meist: Es wird nachgesehen, ob etwas existiert, etwa structuredClone oder Promise.withResolvers, oder ob neuere Syntax akzeptiert wird, zum Beispiel ein regulärer Ausdruck mit dem Flag v. Die CSS-Zeilen laufen über CSS.supports(); das meldet, ob die Style-Engine eine Eigenschaft, einen Wert oder einen Selektor wie :has() versteht. Die Codec-Zeilen verwenden die Antworten, die der Browser selbst auf canPlayType() und auf Media-Source-Prüfungen gibt.
Keine Prüfung öffnet eine Berechtigungsabfrage, startet eine Geräteauswahl oder sendet etwas über das Netzwerk. Bei Hardware-APIs wie Web Bluetooth, WebUSB oder Web NFC bedeutet „unterstützt“, dass der Browser die Schnittstelle bereitstellt – nicht, dass ein Gerät angeschlossen oder freigegeben ist.
So gehst du vor
- Öffne die Seite genau in dem Browser, Profil und Gerät, um die es dir geht. Die Prüfungen starten von selbst.
- Lies die Zusammenfassung und geh dann jede Gruppe nach Zeilen durch, die als nicht unterstützt markiert sind.
- Achte in der Gruppe Medien auf Codecs mit „Teilweise“. Dann hat der Browser mit maybe geantwortet statt mit probably.
- Klicke auf „Als Text kopieren“, um die ganze Liste in die Zwischenablage zu legen.
- Füge sie in den Fehlerbericht, das Ticket oder den Chat ein und ergänze Browserversion und Betriebssystem, falls sie dort noch nicht stehen.
Teste im selben Fenster, in dem das Problem auftritt. Erweiterungen, Unternehmensrichtlinien und experimentelle Flags können einzelne Funktionen ein- oder ausschalten.
Zwei Zeilen beschreiben ebenso sehr die Seite wie den Browser: Ob ein sicherer Kontext vorliegt, hängt davon ab, wie die Seite geladen wurde, und die Cross-Origin-Isolation von den Headern, die der Server sendet. Auf einer anderen Website können genau diese beiden Antworten anders ausfallen.
Wofür du das brauchen kannst
- Support-Tickets. Eine Kundin meldet, dass beim Speichern einer großen Datei nichts passiert. Bitte sie, diese Seite zu öffnen und die kopierte Liste zu schicken; fehlt die Zeile Origin Private File System oder Fetch mit Streams, ist die Sache oft schon mit einer Antwort geklärt.
- Videos, die nicht laufen. Ein Clip spielt auf einem Laptop und zeigt auf einem anderen nur ein schwarzes Bild. Vergleiche auf beiden Geräten die Zeilen für HEVC und AV1; steht dort Nein oder Teilweise, solltest du zusätzlich eine H.264- oder VP9-Fassung ausliefern.
- Entscheiden, was live gehen kann. Bevor du dich auf
:has(), Container Queries oder CSS-Nesting verlässt, öffne die Seite in den ältesten Browsern, die deine Nutzer noch verwenden, auch auf Info-Terminals und Smart-TVs. - In-App-Browser. Links, die man in Chat- und Social-Media-Apps antippt, öffnen sich oft in einer eingebetteten Webansicht (WebView). Rufst du diese Seite auf diesem Weg auf, siehst du, was die Webansicht unterstützt – und das kann von Safari oder Chrome auf demselben Handy abweichen.
- Hardware-Projekte. Bevor du Nutzern versprichst, dass sie einen Mikrocontroller flashen oder eine Tastatur über eine Webseite konfigurieren können, lass sie die Zeilen Web Serial, WebUSB und WebHID prüfen; einigen großen Browsern fehlen diese Schnittstellen komplett.
Feature-Erkennung statt User-Agent-Sniffing
Früher war es üblich, den User-Agent-String auszulesen und vom Browsernamen auf die Fähigkeiten zu schließen. Das geht auf vorhersehbare Weise schief. Chromium-basierte Browser teilen sich den größten Teil ihres User-Agent-Texts. Chrome auf dem iPhone trägt zwar das Token CriOS, rendert aber normalerweise mit WebKit und verhält sich deshalb bei den meisten Zeilen hier wie Safari. Chrome hat außerdem Teile der Versions- und Plattformangaben in seinem String eingefroren, und jeder kann den String mit ein paar Klicks ändern.
Feature-Erkennung fragt stattdessen den Browser, der gerade läuft. Das macht auch Progressive Enhancement einfach: Du baust eine Grundversion, die überall funktioniert, und ergänzt den besseren Weg nur dort, wo die Prüfung besteht.
if ('share' in navigator) {
shareButton.hidden = false; // natives Teilen-Menü
} else {
copyLinkButton.hidden = false; // einfache Alternative
}@supports (container-type: inline-size) {
.card-list { container-type: inline-size; }
}Bei Codecs funktioniert das genauso. Ein Player kann video.canPlayType('video/mp4; codecs="av01.0.05M.08"') aufrufen und auf eine H.264-Quelle ausweichen, wenn die Antwort ein leerer String ist – so sagt der Browser Nein. Die einzigen anderen möglichen Antworten sind maybe und probably.
Warum derselbe Browser unterschiedlich antworten kann
Hardware und Betriebssystem
Viele Zeilen hängen nicht nur vom Browser-Build ab. HEVC braucht zum Abspielen oft einen Hardware-Decoder oder Codec-Unterstützung durch das Betriebssystem, sodass dieselbe Browserversion auf zwei Laptops unterschiedlich antworten kann. Safari meldet AV1 nur auf Apple-Geräten mit AV1-Hardware-Decoder. WebGPU ist auf manchen Betriebssystemen früher erschienen als auf anderen, und ein Browser kann WebGL abschalten, wenn der Grafiktreiber auf seiner Sperrliste steht. Manche Open-Source-Builds von Browsern lassen lizenzpflichtige Codecs wie H.264 und AAC weg.
Sichere Kontexte
Viele APIs gibt es nur in einem sicheren Kontext: auf Seiten, die über https ausgeliefert werden, und unter lokalen Adressen wie http://localhost und http://127.0.0.1. Dazu gehören Service Workers, die asynchrone Clipboard-API, Web Authentication, Web Share, Screen Wake Lock, WebGPU und die Geräte-APIs. Lädst du dieselbe Website über einfaches http unter einer LAN-Adresse, fehlen diese Objekte ganz, statt nur blockiert zu sein – eine Funktion, die auf localhost läuft, kann auf einem Testserver also verschwinden. window.isSecureContext zeigt an, ob ein sicherer Kontext vorliegt. Cross-Origin-Isolation, die SharedArrayBuffer freischaltet, setzt außerdem die Response-Header Cross-Origin-Opener-Policy und Cross-Origin-Embedder-Policy voraus.
Die Liste ist auch ein Fingerprint
Weil die Ergebnisse je nach Browser, Version, Betriebssystem und Hardware verschieden ausfallen, grenzt das vollständige Antwortmuster ein, welches Setup ein Besucher hat. Fingerprinting-Skripte führen genau deshalb dieselbe Art von Prüfungen aus, neben Canvas-Rendering und der Abfrage installierter Schriftarten. Diese Seite prüft lokal und sendet nichts, und iseeu.cc protokolliert weder IP-Adressen noch Abfragen – aber jede Website kann gleichwertigen Code ausführen, ohne dir das Ergebnis zu zeigen. Bevor du die Liste in einen öffentlichen Issue-Tracker stellst, behandle sie wie jedes andere Detail über dein System, das du teilst.
Häufige Fragen
Fragt diese Seite nach der Berechtigung für Kamera, Bluetooth oder Benachrichtigungen?
Nein. Jede Prüfung fragt nur, ob eine API vorhanden ist oder ob der Browser angibt, etwas zu unterstützen. Es wird keine Methode aufgerufen, die eine Berechtigungsabfrage oder eine Geräteauswahl öffnen würde, und keine Daten verlassen deinen Browser. Die Zeile zur Notifications-API zum Beispiel prüft nur, ob die API existiert; sie bittet nicht darum, dir Benachrichtigungen anzeigen zu dürfen. Außerdem setzt iseeu.cc keine Cookies und protokolliert weder IP-Adressen noch Abfragen.
Die Funktion steht auf „Ja“ – warum klappt sie auf meiner Website trotzdem nicht?
„Unterstützt“ heißt hier: Der Browser stellt die API bereit oder gibt an, die Syntax zu verstehen. Im echten Einsatz kann es trotzdem scheitern: Deine Website wird vielleicht über einfaches http geladen und verliert dadurch die APIs, die einen sicheren Kontext brauchen, eine Berechtigung wurde verweigert, eine Richtlinie sperrt ein Gerät, oder WebGPU findet keinen nutzbaren Grafikadapter. Die Codec-Zeilen zeigen, was der Browser behauptet; ein ungewöhnliches Profil oder eine ungewöhnliche Auflösung kann sich trotzdem nicht dekodieren lassen.
Was bedeutet „Teilweise“ bei den Codecs?
Die Methode canPlayType antwortet nie mit Ja. Sie liefert probably, wenn der Browser ziemlich sicher ist, das Format abspielen zu können, maybe, wenn er das Format erkennt, es aber ohne Versuch nicht sicher sagen kann, und einen leeren String für Nein. Diese Seite zeigt maybe als „Teilweise“ an. Nimm ein solches Ergebnis zum Anlass, die Wiedergabe mit deiner eigenen Datei wirklich zu testen, bevor du dich auf den Codec verlässt.
Warum bekommt mein Kollege mit derselben Browserversion andere Ergebnisse?
Mehrere Zeilen hängen eher vom Betriebssystem und von der Hardware ab als von der Browserversion. HEVC und AV1 sind oft auf Hardware-Decoder angewiesen, ob WebGPU verfügbar ist, hängt von Plattform und Grafiktreiber ab, und manche Builds werden ohne lizenzpflichtige Codecs ausgeliefert. Auch Erweiterungen, Unternehmensrichtlinien, experimentelle Flags und private Fenster können einzelne Antworten ändern. Am schnellsten findest du den Unterschied, wenn ihr beide die Liste kopiert und die zwei Fassungen nebeneinanderlegt.
Warum fehlen manche Funktionen, wenn ich eine Website über http öffne?
Browser stellen viele neuere APIs nur in sicheren Kontexten bereit, also auf Seiten, die über https oder von lokalen Adressen wie localhost geladen werden. Auf einer Seite mit einfachem http sind Objekte wie navigator.serviceWorker und navigator.clipboard schlicht undefiniert. Das ist Absicht: Diese APIs greifen auf Geräte, Zugangsdaten oder langlebigen Hintergrundcode zu, und eine unverschlüsselte Seite könnte unterwegs verändert werden. Liefere Testumgebungen über https aus, dann verhalten sie sich wie die Produktion.
Kann man mich anhand dieser Liste identifizieren?
Für sich genommen beschreibt eine Liste unterstützter Funktionen deinen Browser, dein Betriebssystem und deine Hardware, nicht dich. Zusammen mit anderen Signalen wie Bildschirmgröße, installierten Schriftarten und Canvas-Ausgabe trägt sie aber zu einem Browser-Fingerprint bei, über den sich wiederkehrende Besucher erkennen lassen. Diese Seite prüft lokal und sendet nichts. Andere Websites können dieselben Tests jedoch unbemerkt ausführen – das Risiko liegt also in der Kombination, nicht in dieser Liste allein.
Wäre es nicht einfacher, den User-Agent auszulesen?
Um zu entscheiden, ob du eine Funktion nutzen kannst: nein. Chromium-basierte Browser teilen sich weitgehend denselben User-Agent-String, Chrome hat die Angaben darin gekürzt, der String lässt sich leicht ändern, und auf dem iPhone führt er in die Irre, weil Chrome und Firefox dort normalerweise mit WebKit rendern. Wer die Funktion direkt testet, bekommt die Antwort des Browsers, der tatsächlich läuft. Für einen Fehlerbericht ist der User-Agent-String trotzdem nützlich, um die genaue Browserversion festzuhalten.
Wie gebe ich die Ergebnisse an den Support weiter?
Öffne die Seite im selben Browser, Profil und Gerät, in dem das Problem auftritt, klicke auf „Als Text kopieren“ und füge die Liste in das Ticket, den Fehlerbericht oder den Chat ein. Ergänze Browserversion und Betriebssystem, falls sie noch fehlen. Bevor du die Liste in einem öffentlichen Issue-Tracker postest, behandle sie wie jedes andere Systemdetail, das du teilst.
Die Erkennung meldet, was der Browser bereitstellt oder zu können angibt. Eine Funktion kann trotzdem an einer Richtlinie, fehlender Hardware oder einer verweigerten Berechtigung scheitern, sobald eine Website sie tatsächlich nutzen will.