1996: Das PNG-Komitee plant weiter

Die Geschichte von MNG ist die seltene Geschichte eines Format-Standards, der alles „richtig" machte und trotzdem scheiterte. Sie beginnt 1996, im selben Jahr, in dem PNG (siehe unsere PNG-Geschichte) als Patent-freier GIF-Ersatz erschien. Das PNG-Entwicklungs-Komitee saß nach der erfolgreichen Spezifikation zusammen und überlegte: was als Nächstes?

GIF konnte zwei Dinge, die PNG nicht konnte: Animation und Multi-Image-Container. Das Komitee, immer noch unter dem Einfluss von Thomas Boutell, beschloss, eine separate Spezifikation für animierte und mehrfach-eingebettete Bild-Inhalte zu entwickeln. Der Name: Multi-Image Network Graphics (MNG).

Die Ambition: alles im PNG-Ökosystem

MNG sollte mehr sein als ein animiertes PNG. Es war als universeller Multi-Image-Container konzipiert, der mehrere statische und animierte Inhalte kombinieren konnte. Die Spezifikation beschrieb:

  • Animations-Sequenzen. Mehrere PNG-Frames hintereinander mit Timing-Steuerung.
  • Multi-Layer-Composite. Mehrere Bilder gleichzeitig übereinander gerendert, jedes mit eigenem Alpha-Kanal.
  • Sub-Sequenz-Loops. Verschachtelte Animations-Loops mit eigener Steuerung — Inception-artige Animations-Schachteln.
  • Object-Referenzen. Ein Bild konnte im Container nur einmal gespeichert und mehrfach referenziert werden.
  • Delta-Frames. Wie bei Video-Codecs nur die veränderten Pixel zwischen Frames.
  • Frame-Disposal-Methoden. Wie GIF, aber mit mehr Granularität.

Diese Ambition machte MNG zu einem konzeptionell faszinierenden Format. Theoretisch konnte ein MNG fast alles, was Flash später anbot, aber in einem Bildformat-Container. Eine vollständige Animation mit mehreren animierten Schichten, transparenten Hintergründen und interaktiver Timing-Kontrolle — alles in einer Datei.

JNG: JPEG im PNG-Container

Eine besonders eigenwillige Komponente war JNG (JPEG-Network-Graphics)— eine Sub-Spezifikation, die JPEG-komprimierte Daten in einem PNG-ähnlichen Container erlaubte. Die Idee: ein MNG konnte Animations-Frames mischen — manche als verlustfreie PNGs, manche als verlustbehaftete JPEGs/JNGs, je nach Inhalt. Foto-Hintergründe als JNG, UI-Overlays als PNG, alles in einem MNG-Container.

JNG selbst gewann nie eigene Adoption. Es existierte nur als Teil von MNG und wurde implementiert, indem JNG-Decoder zusätzliche JPEG-Codecs in PNG-Bibliotheken einbinden mussten — eine Architektur, die Software-Hersteller verständlich abschreckte.

Die Komplexitäts-Falle

MNGs Hauptproblem war seine eigene Vollständigkeit. Die finale Spezifikation (Version 1.0, ratifiziert Februar 2001) war über 100 Seiten lang. Im Vergleich: die GIF-Spezifikation passt auf 13 Seiten, die PNG-Spezifikation auf etwa 50. Ein MNG-Encoder oder Decoder zu implementieren war ein massives Projekt — vermutlich 10–20 Mal so aufwendig wie ein vergleichbarer PNG- oder GIF-Codec.

Diese Komplexität war strategisch ein Fehler. Browser-Hersteller hatten knappe Code-Budget-Ressourcen und priorisierten Features mit klarem Mehrwert. Ein MNG-Decoder, der nur eine Nischen-Demand befriedigte, war kommerziell uninteressant. GIF reichte für die meisten Animations-Fälle; alles darüber hinaus war Flash-Domäne.

2001: Mozilla baut einen Decoder

Trotz aller Probleme nahm Mozilla MNG ernst. Die Mozilla-Suite (der direkte Vorgänger von Firefox) bekam 2001 nativen MNG-Decoder-Support, basierend auf der Open-Source- Bibliothek libmng. Mozilla war kurzzeitig der erste und einzige große Browser, der MNG-Animationen rendern konnte.

Die Wirkung blieb aus. Web-Entwickler nutzten MNG kaum. Es gab praktisch keine MNG-Authoring-Tools, kein Adobe-Plugin, keine breite Bibliothek von MNG-Beispielen. Wer eine animierte Grafik brauchte, blieb bei GIF — auch mit allen Limitierungen — oder wechselte zu Flash.

2003: Mozilla zieht den Stecker

Im Mai 2003 entfernte Mozilla den nativen MNG-Support aus dem Browser. Die Begründung war pragmatisch und ehrlich: der libmng-Code war komplex und hatte Sicherheits-Implikationen, niemand nutzte MNG ernsthaft im Web, und die Software-Wartung lohnte nicht. Die Entscheidung wurde von der Community kritisiert, aber nicht zurückgenommen.

Damit war MNG faktisch tot. Ohne Mozilla-Support war es kein Web-Format mehr; ohne Web-Support gab es keinen Grund, MNG-Tools zu pflegen. Die offizielle Spezifikation existiert weiter, aber praktisch niemand implementiert sie.

Das Erbe: APNG

MNGs Scheitern war direkt der Auslöser für APNG (siehe unsere APNG-Geschichte). Mozilla-Entwickler erkannten 2004: was wir brauchen, ist kein komplexer Multi-Image-Container, sondern eine minimal-invasive Animation-Erweiterung zu PNG. APNG entstand explizit als pragmatische Antwort auf das MNG-Scheitern — rückwärts-kompatibel, einfach implementierbar, sofort nützlich.

Das PNG-Komitee lehnte APNG ab, mit dem Argument, MNG existiere bereits. Mozilla ignorierte die Ablehnung und implementierte APNG trotzdem. Heute ist APNG in jedem Browser standardmäßig unterstützt; MNG existiert nur noch in Archiv-Dokumenten.

Was MNG uns über Standards lehrt

MNG ist ein wertvolles Lehrstück für Standards-Design. Drei Schlussfolgerungen:

  • Komplexität bestraft sich selbst. Ein Standard, dessen Implementierung 100 Manntage kostet, wird ignoriert. Ein Standard, der in einem Wochenende implementierbar ist, hat eine Chance.
  • Rückwärts-Kompatibilität ist Schlüssel. APNG-Dateien können überall hochgeladen werden, wo PNGs akzeptiert werden. MNG brauchte eigene Datei-Endung und eigene Pipeline — eine Hürde, die nie überwunden wurde.
  • Praktische Demand schlägt theoretische Ambition. MNG konnte theoretisch alles, was Flash konnte, aber niemand brauchte das in einem Bildformat. APNG konnte nur „einfache Animation", aber genau die wurde gebraucht.

2026: MNG in Archiv-Status

Die offizielle MNG-Spezifikation ist unverändert verfügbar, die libmng-Bibliothek existiert noch auf SourceForge, aber in der täglichen Web-Praxis spielt MNG keine Rolle. Wer eine alte MNG-Datei vorfindet — selten, aber möglich in archivierten Geocities-Sites oder frühen Open-Source-Tutorials —, sollte sie zu animiertem WebP, AVIF oder GIF konvertieren. Open-Source-Tools wie ImageMagick können MNG noch lesen und in moderne Formate exportieren.

Für moderne Animations-Workflows ist die Wahl klar: APNG für verlustfreie UI- Animationen, animiertes WebP für Foto-Inhalte mit kleinerem Speicher, animiertes AVIF für maximale Komprimierung. Eine Tiefen-Diskussion zu animierten Web-Formaten findest du in unserem GIF-vs.-WebP-Beitrag.

Wann MNG die richtige Wahl ist

Praktisch nie. MNG ist 2026 ein historisches Format ohne Modern-Web-Anwendungsfall. Die einzigen relevanten Szenarien sind: Format-Migration alter Archive zu modernen Animations-Formaten, akademische Forschung zur Geschichte der Web-Standards, oder Trivia-Wissen für Tech-Diskussionen.

Quellen

libmng — Offizielle Bibliothek · MNG Home Page (PNG-Group) · W3C — MNG 1.0 Recommendation (2001) · Mozilla Bugzilla — MNG Removal Discussion · Wikipedia — MNG · Wikipedia — JNG (JPEG Network Graphics) · Randers-Pehrson, G., „MNG: Multiple-image Network Graphics", PNG Development Group 2001.