1996: The PNG committee keeps planning
The history of MNG is the rare story of a format standard that did everything "right" and failed anyway. It begins in 1996, the same year that PNG (see our PNG history) appeared as a patent-free replacement for GIF. After the successful specification, the PNG development committee sat down together and wondered: what next?
GIF could do two things PNG could not: animation and a multi-image container. The committee, still under the influence of Thomas Boutell, decided to develop a separate specification for animated and multiply-embedded image content. The name: Multi-Image Network Graphics (MNG).
The ambition: everything within the PNG ecosystem
MNG was meant to be more than just an animated PNG. It was conceived as a universal multi-image container that could combine multiple static and animated pieces of content. The specification described:
- Animation sequences. Multiple PNG frames in a row with timing control.
- Multi-layer compositing. Multiple images rendered on top of each other simultaneously, each with its own alpha channel.
- Sub-sequence loops. Nested animation loops with their own control — Inception-style animation boxes within boxes.
- Object references. An image could be stored only once in the container and referenced multiple times.
- Delta frames. Like video codecs, only the pixels that changed between frames.
- Frame disposal methods. Like GIF, but with more granularity.
This ambition made MNG a conceptually fascinating format. In theory, an MNG could do almost everything Flash would later offer, but inside an image-format container. A complete animation with multiple animated layers, transparent backgrounds and interactive timing control — all in a single file.
JNG: JPEG in a PNG container
One particularly idiosyncratic component was JNG (JPEG Network Graphics) — a sub-specification that allowed JPEG-compressed data inside a PNG-like container. The idea: an MNG could mix animation frames — some as lossless PNGs, some as lossy JPEGs/JNGs, depending on the content. Photographic backgrounds as JNG, UI overlays as PNG, all in one MNG container.
JNG itself never gained adoption of its own. It existed only as part of MNG and was implemented by requiring JNG decoders to embed additional JPEG codecs into PNG libraries — an architecture that understandably deterred software vendors.
The complexity trap
MNG's main problem was its own completeness. The final specification (version 1.0, ratified in February 2001) was over 100 pages long. By comparison: the GIF specification fits on 13 pages, the PNG specification on about 50. Implementing an MNG encoder or decoder was a massive project — probably 10–20 times as much effort as a comparable PNG or GIF codec.
This complexity was a strategic mistake. Browser makers had scarce code-budget resources and prioritized features with clear added value. An MNG decoder that satisfied only a niche demand was commercially uninteresting. GIF was enough for most animation cases; anything beyond that was Flash territory.
2001: Mozilla builds a decoder
Despite all the problems, Mozilla took MNG seriously. The Mozilla Suite (the direct predecessor of Firefox) gained native MNG decoder support in 2001, based on the open-source library libmng. For a brief moment, Mozilla was the first and only major browser that could render MNG animations.
The impact never materialized. Web developers barely used MNG. There were practically no MNG authoring tools, no Adobe plugin, no broad library of MNG examples. Anyone who needed an animated graphic stuck with GIF — despite all its limitations — or switched to Flash.
2003: Mozilla pulls the plug
In May 2003, Mozilla removed native MNG support from the browser. The reasoning was pragmatic and honest: the libmng code was complex and had security implications, nobody was seriously using MNG on the web, and the software maintenance was not worth it. The decision was criticized by the community, but not reversed.
With that, MNG was effectively dead. Without Mozilla support it was no longer a web format; without web support there was no reason to maintain MNG tools. The official specification still exists, but practically nobody implements it.
The legacy: APNG
MNG's failure was the direct trigger for APNG (see our APNG history). In 2004, Mozilla developers realized: what we need is not a complex multi-image container, but a minimally invasive animation extension to PNG. APNG emerged explicitly as a pragmatic answer to the MNG failure — backward-compatible, easy to implement, immediately useful.
The PNG committee rejected APNG, arguing that MNG already existed. Mozilla ignored the rejection and implemented APNG anyway. Today, APNG is supported by default in every browser; MNG exists only in archival documents.
What MNG teaches us about standards
MNG is a valuable cautionary tale for standards design. Three conclusions:
- Complexity punishes itself. A standard whose implementation costs 100 person-days will be ignored. A standard that can be implemented in a weekend has a chance.
- Backward compatibility is key. APNG files can be uploaded anywhere PNGs are accepted. MNG needed its own file extension and its own pipeline — a hurdle that was never overcome.
- Practical demand beats theoretical ambition.MNG could theoretically do everything Flash could, but nobody needed that inside an image format. APNG could only do "simple animation", but that was exactly what was needed.
2026: MNG in archival status
The official MNG specification is still available unchanged, the libmng library still exists on SourceForge, but in day-to-day web practice MNG plays no role. Anyone who comes across an old MNG file — rare, but possible on archived Geocities sites or early open-source tutorials — should convert it to animated WebP, AVIF or GIF. Open-source tools like ImageMagick can still read MNG and export it to modern formats.
For modern animation workflows the choice is clear: APNG for lossless UI animations, animated WebP for photographic content with smaller storage, animated AVIF for maximum compression. You can find an in-depth discussion of animated web formats in our GIF-vs-WebP post.
When MNG is the right choice
Practically never. In 2026, MNG is a historical format with no modern-web use case. The only relevant scenarios are: format migration of old archives to modern animation formats, academic research into the history of web standards, or trivia knowledge for tech discussions.
Sources
libmng — Official library · 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.