READ ALSO: Image Variants in Web Applications
READ ALSO: Images in Web Applications
READ ALSO: Brief History of Images in Software
In the early history of the Web, GIF was the first widely used image format. Short for Graphics Interchange Format, it was introduced by CompuServe in 1987, well before JPEG became practical for the Web.
Interestingly, CompuServe was one of the major commercial online services in the United States, operating well before today’s Internet became widely accessible. By the late 1970s and 1980s, it offered consumers dial-up access to services such as email, forums, news, file downloads, and online games. It was part of the pre-Web world of commercial online services, operating as a proprietary network rather than as part of the open Internet we know today.
CompuServe devised GIF as a way to enrich these services with graphics. The format was designed for relatively simple images and was particularly well suited to the bandwidth limitations of the time. It used lossless Lempel-Ziv-Welch (LZW) compression and an indexed color palette limited to 256 colors. A successive specification in 1989 added features such as transparency and animation.
That 256-color limitation, however, made GIF poorly suited to photographic images. JPEG offered a fundamentally different solution: it could represent millions of colors and compress photographic images dramatically more efficiently, albeit with some loss of image information. As the Web evolved from simple graphics toward photographic imagery, this difference would become increasingly important.
JPEG as a Synonym for Image over the Web
I remember very well the early days of JPEG and the industry’s quest for a reliable file format that could help promote digital imaging and photography. Outside the Web, formats such as TIFF and TGA were widely used to store high-quality digital copies of photographs. Yet neither was particularly suited to the easy exchange of images between applications. At a time when storage was measured in megabytes and files were routinely moved on floppy disks, uncompressed (or lightly compressed) images could easily exceed the capacity of a single disk.
Larger sizes were acceptable for the professional digital imaging workflows of the time, but hardly suitable for widespread image exchange. JPEG changed that perspective. By making photographic images dramatically smaller while retaining acceptable visual quality, it opened the door to a very different way of thinking about digital images.
The Fractal Factor
The defining characteristic of FIF technology was its structural asymmetry: very fast to turn bytes into pixels, but very slow at converting read pixels back into bytes on disk. This asymmetry was attractive for distribution, but it also created a problem when moving from experiments to real services. Encoding was computationally intensive, and scaling the process to large numbers of images could require substantial processing power. Iterated Systems therefore pursued hardware acceleration, including dedicated fractal-transform boards and specialized chips designed to speed up the encoding process.
The architecture made sense: spend the computational effort once, when an image entered the system, and then benefit from fast decompression every time the image was requested. For a service handling thousand—or potentially millions—of images, however, the question was no longer simply whether FIF could compress an image. It was whether the encoding process could be scaled economically.
Yet, for a couple of years in the mid-1990s, JPEG and FIF were almost face to face. FIF could produce significantly smaller files while maintaining decent visual quality for a significant range of real-world images. JPEG often produced larger files at comparable quality, but its results were more consistently predictable across all different types of images.
More importantly, JPEG did not suffer from the fundamental asymmetry of FIF. Encoding and decoding were both practical operations, without the enormous computational imbalance between turning pixels into a compressed representation and turning that representation back into pixels. This made JPEG an easier technology to deploy at scale. FIF could win the compression contest on individual images, sometimes by a considerable margin, but JPEG offered a much more balanced and predictable system.
So, JPEG won and FIF faded into obscurity. For the rapidly expanding Web, that balance mattered more than winning the compression contest on individual images. The industry discovered that the valuable thing wasn’t necessarily the compression algorithm itself, but the ability to ingest, store, manage, retrieve and deliver enormous collections of digital images.
Portable Network Graphics
The strength of JPEG was ultimately balance: good visual quality, small files, predictable encoding and decoding, and broad compatibility. It was not perfect though. More or less at the same time another file format—as much popular as JPEG today—came up.
PNG was born in response to a licensing controversy surrounding the LZW compression used by GIF. The name originally stood for Portable Network Graphics, and the format was designed as an open, patent-free alternative for Web graphics. The PNG specification was developed by an informal group of developers and later standardized by the W3C. PNG kept the advantages that made GIF attractive—lossless compression and support for relatively simple graphics—but removed its most important limitations. It supported 24-bit color, allowing millions of colors, and introduced a full alpha channel, making true variable transparency possible. It could therefore represent not only logos, icons and illustrations, but images that could be cleanly composited over arbitrary backgrounds.
PNG was never intended to replace JPEG for photographic images. Its lossless compression generally produces much larger files for photographs. Instead, it occupied a different space: graphics, illustrations, screenshots, interfaces, and any image where sharp edges, exact colors, or transparency mattered.
Together, JPEG and PNG established two fundamental worlds of Web imagery: JPEG for photographs and PNG for graphics and compositing. The formats that followed would build on this foundation, increasingly blurring the boundaries between quality, compression, transparency, animation, and richer visual content.
More Recent Progress
In two decades, the Web changed dramatically. Images were no longer occasional additions to a page but one of its main forms of content. In 2010, Google proposed a format designed specifically for this new Web: WebP.
WebP was based on technology derived from the VP8 video codec and offered both lossy and lossless compression, together with transparency and, later, animation. Its important advantage was that it could cover much of the territory occupied separately by JPEG and PNG, while often requiring fewer bytes to deliver an image. A photograph could be compressed efficiently like a JPEG, while graphics could retain transparency and lossless compression like a PNG. In other words, WebP was not simply trying to produce a better JPEG; it was trying to provide a more versatile image format with better compression across different kinds of content.
The improvement came with trade-offs. Encoding and decoding could be more computationally demanding than with the older formats, and adoption took time as browsers and software had to add support. But the fundamental proposition was powerful: less data over the network without giving up the capabilities that had previously required different image formats.
AVIF arrived later, building on the AV1 video-compression technology developed by the Alliance for Open Media. The AVIF specification emerged in 2019, bringing the advantages of a modern video codec to still images. AVIF pushed the same idea further. It can provide very high compression efficiency for photographs and other complex images, while also supporting transparency, lossless compression, animation, and higher-quality image representations than the formats that came before it. This meant that a single format could address capabilities that previously belonged to different generations of image technology—and often do so with substantially less data than JPEG or PNG.
Again, there was a price. AVIF encoding can be computationally demanding, and decoding can also require more processing than older formats, depending on the implementation and hardware. But by this point the balance had changed. Computers had become enormously more powerful, while moving large amounts of data over the network was still costly. It therefore became increasingly reasonable to spend more computing power to produce smaller image files and reduce the amount of data that had to be transmitted.
JPEG and PNG emerged when the overriding question was how to make images small enough to move across a constrained network. WebP and AVIF emerged when the question had become how to deliver increasingly sophisticated images using as little bandwidth as possible, without sacrificing capabilities such as transparency, animation, and image quality.
Interestingly, in the 1990s, computational cost was so relevant to kill a compression technology (FIF). Decades later, instead, much more computation could be acceptable if it saved network bandwidth.
What About the Browser?
Browsers have traditionally served images through the IMG element. Its src attribute points to a URL, and the browser downloads and displays that image. But the same image may exist in several sizes. A photograph, for example, might be stored as:
- photo-small.jpg
- photo-medium.jpg
- photo-large.jpg
The additional srcset attribute does the trick.
<img src="photo-medium.jpg"
srcset="photo-small.jpg 400w,
photo-medium.jpg 800w,
photo-large.jpg 1600w"
alt="A photograph">
Now the browser can choose. On a small screen it may download the 400-pixel version; on a larger screen it may download the 1600-pixel version. The application does not need to decide this for every device.
The PICTURE element goes one step further. It is used when the alternatives are not simply different sizes of the same image. They may be different formats or different versions of the image itself:
<picture>
<source media="(max-width: 600px)" srcset="photo-mobile.jpg">
<source media="(min-width: 601px)" srcset="photo-desktop.jpg">
<img src="photo-desktop.jpg" alt="A photograph">
</picture>
Here the mobile version could use a tighter crop, while the desktop version shows the full photograph. The media attribute tells the browser when each version is appropriate.
So, there are really two ideas. The srcset attribute lets the browser choose the size of an image; PICTURE lets the browser choose between different versions of an image. In both cases, the application provides the alternatives and the browser decides which physical file to download.
The Bottom Line
In modern Web applications, an image is no longer simply a fixed collection of bytes. It is better understood as a logical object identified by a unique identifier, with a collection of physical representations and related metadata.
The metadata typically lives in a database, while the image files themselves are stored in blob storage. The application organizes these representations and generates the appropriate URLs for retrieving them. A single logical image might therefore correspond to several files: different resolutions, formats, or crops, each suited to a different context.
In this model, the browser becomes part of the image-delivery system. The application provides the alternatives; the browser decides which representation should actually travel across the network.
