MP4 vs. WebM: Das beste Format für Web-Videos im Jahr 2026
Die kurze Antwort (und warum sie kompliziert ist)
Wenn du 2026 nur ein einziges Videoformat für das Web brauchst, lautet die Antwort: MP4 mit H.264-Kodierung. Es gewinnt nach wie vor bei der reinen Kompatibilität. Jeder Browser, jedes Gerät und jeder Smart-TV spielt es ohne Probleme ab. WebM, das die VP9- oder AV1-Kodierung verwendet, bietet eine bessere Kompression und Bildqualität bei gleicher Dateigröße, bringt aber ein paar Nachteile mit sich. Safari hat erst Ende 2024 die volle Hardware-Dekodierung für AV1 erhalten, und einige ältere Android-Geräte können bei VP9 immer noch ins Stottern geraten. Für die meisten Publisher ist die wahre Antwort einfach: Liefere beides aus. Eine WebM-Datei als primäre Quelle mit einem MP4-Fallback deckt 99,8 % der Geräte ab und gibt dir das Beste aus beiden Welten in Bezug auf Qualität und Bandbreite. Das HTML5-<video>-Element macht dies mit mehreren <source>-Tags überraschend einfach. Die eigentliche Komplexität liegt nicht im Code, sondern in der Logistik. Du musst die Kodierungszeit, Speicherkosten, CDN-Gebühren und die Frage berücksichtigen, ob dein CMS oder deine Videoplattform überhaupt den Upload von zwei Versionen derselben Datei zulässt. Dieser Artikel schlüsselt diese Kompromisse mit echten Zahlen auf und hilft dir, eine Lösung für deinen tatsächlichen Workflow zu wählen, nicht nur für ein theoretisches Ideal.
Codec-Analyse: Was wirklich in den Containern steckt
MP4 und WebM sind nur Container. Stell sie dir wie ZIP-Dateien vor, die komprimierte Video- und Audio-Streams enthalten. Das Containerformat selbst ist weitaus weniger wichtig als der Codec, der im Inneren die Schwerstarbeit leistet. MP4-Dateien enthalten fast immer H.264 (AVC)-Video und AAC-Audio. H.264 ist ein uralter Standard aus dem Jahr 2003, aber er wurde über zwei Jahrzehnte lang verfeinert. Ein 1080p H.264-Stream mit 4 Mbit/s sieht auf den meisten Bildschirmen großartig aus. Obwohl MP4 auch H.265 (HEVC) unterstützt, das eine ähnliche Qualität bei halber Bitrate bietet, war seine Verbreitung ein einziges Chaos. Lizenzgebühren machten die Browser-Hersteller zögerlich, und selbst Mitte 2026 dekodiert Chrome HEVC nicht auf allen Plattformen nativ. Google hat WebM als offenes, lizenzfreies Format für das Web entwickelt. Es kann die Codecs VP8, VP9 oder AV1 mit Vorbis- oder Opus-Audio verwenden. VP9 bietet eine 30–50 % bessere Kompression als H.264 bei gleicher Qualität. AV1 geht sogar noch weiter; die internen Tests von YouTube zeigen, dass AV1 Dateien im Vergleich zu VP9 um weitere 30 % verkleinern kann. Aber diese Effizienz hat einen hohen Preis: die Kodierungszeit. Bei seiner langsamsten, qualitativ hochwertigsten Voreinstellung (cpu-used=0) kann die AV1-Kodierung mit libaom 50- bis 100-mal länger dauern als eine Standard-H.264-Kodierung. Für die praktische Web-Veröffentlichung macht dies VP9 in WebM zum Sweet Spot für 2026. Du erhältst erhebliche Kompressionsgewinne gegenüber H.264 und Kodierungsgeschwindigkeiten, die tatsächlich handhabbar sind, ohne dass du eine dedizierte Serverfarm benötigst.
Browser- und Geräte-Support im Jahr 2026
Der Browser-Support ist ein sich ständig änderndes Ziel. Hier ist die aktuelle Lage Mitte 2026. Der Support für MP4/H.264 ist einfach: Er ist universell. Chrome, Firefox, Safari, Edge, Opera, Samsung Internet – jeder große Browser auf jeder Plattform beherrscht es nativ. Keine Ausnahmen, keine Fußnoten. WebM/VP9 wird ebenfalls breit unterstützt und ist in Chrome (seit v29), Firefox (seit v28), Edge (seit v14) und Opera verfügbar. Apple hat die VP9-Unterstützung schließlich 2020 in Safari 14 hinzugefügt, was iOS 14 und macOS Big Sur abdeckt. Der Haken? Geräte, die auf iOS 13 oder früher festsitzen, ein kleiner, aber realer Teil des Traffics, können kein VP9-WebM abspielen. Geh nicht einfach davon aus, dass das nicht deine Zielgruppe ist; schau in deine Analytics. Nutzer im Unternehmens- und Bildungsbereich haben oft überraschend lange Zyklen für Geräte-Upgrades. Die Unterstützung für WebM/AV1 ist viel besser als noch vor ein paar Jahren. Chrome, Firefox und Edge dekodieren AV1 schon eine Weile. Auf der Apple-Seite erhalten Safari auf Apple-Silicon-Macs sowie das iPhone 15 Pro und neuere Modelle eine hardwarebeschleunigte AV1-Dekodierung. Ältere iPhones greifen auf Software-Dekodierung zurück, was den Akku leer frisst und bei 4K-Videos zu Frame-Drops führen kann. Software-Dekodierung ist ein Rezept für ein heißes Handy und einen unzufriedenen Nutzer. Wenn deine Zielgruppe stark iOS-basiert ist und dir ihre Akkulaufzeit am Herzen liegt, ist VP9 der sicherere WebM-Codec. Unterm Strich: Für eine allgemeine Website mit einer Mischung aus Desktop- und Mobilnutzern ist eine primäre WebM/VP9-Quelle mit einem MP4/H.264-Fallback die sicherste und cleverste Konfiguration.
Dateigröße und Qualität: Echte Zahlen
Abstrakte Behauptungen über Kompressionsraten helfen bei Speicherbudgets nicht weiter. Schauen wir uns einige reale Zahlen von einem 2-minütigen 1080p 30fps Quellclip an, der mit FFmpeg und der Pipeline von CocoConvert kodiert wurde. Unsere Basis ist MP4 mit H.264 (x264, CRF 23, Voreinstellung „medium“), das auf 87 MB kommt. Das ist der Standard für viele Entwickler, und die Qualität ist solide, mit einem VMAF-Score von etwa 93 für diesen Clip. Der Wechsel zu WebM mit VP9 (libvpx-vp9, CRF 33, Two-Pass) reduziert die Dateigröße auf 54 MB. Der VMAF-Score ist mit 94 etwas höher, was bedeutet, dass es eine kleinere Datei mit geringfügig besserer Qualität ist. Diese Effizienz ist nicht umsonst; die Two-Pass-Kodierung dauerte auf derselben Maschine etwa viermal länger als die H.264-Version. Eine AV1-Kodierung in einem WebM-Container (libaom-av1, CRF 30, cpu-used=4) bringt uns auf nur 41 MB, mit einem VMAF-Score von 95. Die Einstellung `cpu-used=4` ist ein guter Kompromiss, deutlich schneller als die nahezu unbrauchbare Einstellung `cpu-used=0`, aber immer noch etwa 12-mal langsamer als unsere H.264-Basis. Was bedeutet das für dein Budget? Für eine Website mit 500 Produktvideos von durchschnittlich 90 Sekunden reduziert der Wechsel von einer reinen H.264-Strategie zu einem VP9-First-Ansatz den primären Videospeicher von rund 3,2 TB auf nur 2,0 TB. Bei typischen CDN-Preisen von 0,02 € bis 0,08 € pro GB summieren sich diese Speicher- und Bandbreiteneinsparungen schnell, wenn du skalierst. Eine kurze Anmerkung zu den AV1-Einstellungen von CocoConvert: Um Konvertierungen auf einer geteilten Infrastruktur schnell zu halten, wird `cpu-used=5` verwendet. Wenn du die absolut höchste Qualität für AV1-Kodierungen zur Archivierung benötigst (`cpu-used=0` oder `1`), brauchst du ein lokales FFmpeg-Setup oder einen dedizierten Transcoding-Dienst, bei dem du diese Voreinstellungen konfigurieren kannst.
Wann du MP4 statt WebM wählen solltest
Manchmal ist MP4 nicht nur der Fallback – es ist die einzig sinnvolle Wahl. WebM ist großartig für die Auslieferung im Web, hat aber in einigen Schlüsselbereichen Schwächen. **E-Mail und Messaging:** Eingebettetes Video in E-Mails ist ein berüchtigtes Minenfeld. Outlook unter Windows ignoriert deinen HTML5-Video-Tag komplett. Während Apple Mail MP4s unter iOS inline abspielt, wird kein großer Client eine WebM-Datei anrühren. Für E-Mail-Kampagnen ist MP4 deine einzige Option. **Video-Downloads:** Wenn du Nutzern erlaubst, Videos zum Offline-Anschauen herunterzuladen, liefere ihnen ein MP4. Während ein Power-User mit VLC alles abspielen kann, können die Standard-Mediaplayer unter Windows, macOS und den meisten Smart-TVs nicht mit WebM umgehen. Die Verwendung von MP4 erspart dir eine Flut von Support-Tickets mit der Meldung „Das Video lässt sich nicht abspielen“. **Uploads in sozialen Medien:** Jede soziale Plattform – Twitter/X, Instagram, TikTok, LinkedIn, Facebook – ist auf MP4 aufgebaut. Sie akzeptieren MP4s und transkodieren sie auf ihrer Seite. Die meisten werden einen WebM-Upload rundheraus ablehnen oder, schlimmer noch, ihn zu einem unansehlichen Brei verarbeiten. Exportiere Social-Media-Inhalte immer als MP4. **Ältere CMS-Plattformen:** Bevor du Stunden damit verbringst, eine Bibliothek von WebM-Dateien zu kodieren, prüfe, ob deine Plattform sie überhaupt verwenden kann. Ältere WordPress-Plugins, bestimmte LMS-Systeme und sogar einige Versionen von Wistia akzeptieren nur MP4-Uploads. Ein kurzer Blick in die Dokumentation kann dir eine Menge Kopfschmerzen ersparen. **Hardware und Bearbeitung:** Dein Quellmaterial von Kameras, Bildschirmrekordern und Capture-Karten wird fast immer MP4 oder MOV sein. WebM ist ein Auslieferungsformat, kein Produktionsformat. Kein professioneller Videoeditor verwendet es für Projekte. Es ist für die Ziellinie, nicht für die Startlinie.
Die Implementierung beider Formate: HTML und Workflow
Beide Formate auszuliefern ist viel einfacher, als die meisten Entwickler denken. Die Magie liegt im HTML5-<video>-Element, das jeden <source>-Tag der Reihe nach prüft und den ersten abspielt, den es versteht. <video controls width="1280" height="720" preload="metadata"> <source src="/video/product-demo.webm" type="video/webm; codecs=vp9,opus"> <source src="/video/product-demo.mp4" type="video/mp4"> Dein Browser unterstützt kein HTML5-Video. </video> Moderne Browser, die mit VP9-WebM umgehen können, spielen die erste Quelle ab. Alle anderen greifen elegant auf das MP4 zurück. Die Angabe des `codecs`-Parameters im `type`-Attribut ist eine clevere Optimierung; sie lässt den Browser noch schneller entscheiden, ohne einen Teil der Datei herunterladen zu müssen. Der Workflow zur Erstellung beider Dateien aus einer einzigen Master-Datei ist unkompliziert. Das Stapelverarbeitungs-Tool von CocoConvert kann einen Ordner mit Quelldateien entgegennehmen und gleichzeitig sowohl MP4 als auch WebM ausgeben. Lade einfach deinen Master hoch, wähle „MP4 (H.264)“ und „WebM (VP9)“ als gewünschte Ausgabeformate, stelle deine Qualitätseinstellungen ein, und du erhältst ein ZIP mit beiden Versionen. Für typische 1080p-Webvideos liefert ein CRF von 23 für H.264 und 33 für VP9 eine nahezu identische visuelle Qualität. Hier ist ein entscheidender Tipp für die Automatisierung: Halte deine Dateinamen bis auf die Erweiterung identisch (z. B. `product-demo.webm` und `product-demo.mp4`). Dies macht es für dein Templating-System trivial, die `<source>`-Pfade zu erstellen, ohne für jedes Video einen Datenbank-Lookup zu benötigen. Es ist wichtig, die Grenzen dieses Ansatzes zu kennen. CocoConvert generiert derzeit keine adaptiven Bitraten-Streams (ABR) wie HLS oder DASH. Wenn du es mit langen Videos zu tun hast, bei denen Nutzer in der Zeitleiste springen oder unterschiedliche Netzwerkgeschwindigkeiten haben, benötigst du ABR. Dies erfordert eine dedizierte Videoplattform (wie Mux, Cloudflare Stream oder Bunny.net) oder ein komplexeres, selbst gehostetes FFmpeg-Setup. Für kürzere Clips unter 10 Minuten ist diese Methode der Auslieferung einer einzelnen WebM/MP4-Datei jedoch völlig in Ordnung.
Das Fazit für 2026
Rein technisch gesehen ist WebM mit VP9 das bessere Format für Web-Videos im Jahr 2026. Es liefert kleinere Dateien bei gleicher oder besserer Qualität, und die Browser-Unterstützung ist mittlerweile breit genug, um es zur primären Wahl für die meisten Websites zu machen. AV1 ist der Thronfolger, aber seine hohen Kodierungskosten und die verbleibenden Lücken bei der iOS-Hardwareunterstützung bedeuten, dass es immer noch eine strategische Wahl ist, kein einfacher Standard. Aber MP4 mit H.264 ist weit davon entfernt, veraltet zu sein. Es bleibt absolut unerlässlich als dein universeller Fallback. Es ist auch das einzige Format, das für E-Mails, Social-Media-Uploads, Downloads und viele ältere Plattformen funktioniert. Es wird so schnell nicht verschwinden. Meine praktischen Empfehlungen sind also: * **Allgemeine Website-Videos:** Verwende WebM/VP9 als primäre Quelle, mit einem MP4/H.264-Fallback. * **Social Media & E-Mail:** Nur MP4. Keine Ausnahmen. * **Herunterladbare Dateien:** Nur MP4, um die Kompatibilität zu maximieren. * **Websites mit hohem Traffic:** Wenn CDN-Kosten ein Hauptanliegen sind, lohnt es sich, einen mehrstufigen Fallback zu prüfen: AV1 für die neuesten Browser, dann VP9, dann H.264. * **Sehr kurze Clips (< 30s):** Bei sehr kurzen Videos ist der Unterschied in der Dateigröße minimal. Nur bei MP4 zu bleiben ist einfacher und völlig in Ordnung. Letztendlich balancierst du vier Dinge aus: Kompatibilität, Dateigröße, Kodierungszeit und die Komplexität deines Workflows. Die richtige Antwort hängt ganz von den Geräten deiner Zielgruppe, deinem Hosting-Budget und der Zeit ab, die du in deine Video-Pipeline investieren möchtest. Für die meisten kleinen bis mittelgroßen Websites ist der Ansatz mit zwei Formaten ein fantastischer Kompromiss. Die Einrichtung dauert weniger als eine halbe Stunde und spart sofort Bandbreite, ohne Kompatibilitätsprobleme zu verursachen.