Did you know...?LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.
The International Image Interoperability Framework, or IIIF ("triple-eye eff"), is a small set of standards that form a basis for serving, displaying, and reusing image data on the web. It consists of a number of API definitions that compose with each other to achieve a standard for providing, for example, presentations of high-resolution images at multiple zoom levels, as well as bundling multiple images together. Presentations may include metadata about details like authorship, dates, references to other representations of the same work, copyright information, bibliographic identifiers, etc. Presentations can be further grouped into collections, and metadata can be added in the form of transcriptions, annotations, or captions. IIIF is most popular with cultural-heritage organizations, such as libraries, universities, and archives.
Collections and presentations can—and often do—link to images hosted at many different web sites. A key strength of the framework is standardizing complex, feature-rich image hosting with the explicit goal of interoperable referencing and grouping into combined presentations.
Audience and implementers
IIIF is mostly used by public-sector organizations that deal with heritage science and digital humanities, the core audience being the galleries, libraries, archives, and museums (GLAM) field. The greatest benefits of IIIF are gained when there are few (or no) legal or technical restrictions placed on the content being served, which in practice means works that are born in the public domain or whose copyright has expired.
Among IIIF users likely to be of interest to LWN readers are Wikimedia Commons and the Internet Archive. Wikimedia started tentative integration work in 2018 in the form of IIIF manifests in Wikidata properties, but it seems that further deployment is on hold. The Internet Archive started integrating IIIF in 2015 and officially adopted it in 2023.
The image server at the heart of it
The "How It Works" page on the IIIF website does a good job of explaining the basics of the framework's technical principles, but I will provide an overview of my own here. At the core of IIIF is the Image API, simply defined as a URL with this format:
https://example.org/{id}/{region}/{size}/{rotation}/{quality}.{format}
Here, id is a string that identifies an image, and region is an expression that crops a portion, for example "full" for the entire image or "50,100,200,300" for "50 pixels right, 100 down, 200 wide, 300 high". size specifies how much to downscale the image after cropping, if at all. rotation requests a rotation in degrees, quality can be "default", "grayscale" or one of a few more predefined keywords, and, finally, format is the file extension of the desired image format, usually jpg.
For example, let's look at a Map of Colorado from 1882 hosted by the Library of Congress. A direct URL to the full map, downscaled to 800 pixels wide, looks like this (split for readability):
https://tile.loc.gov/image-services/iiif
/service:gmd:gmd370m:g3700m:g3700m:gla00130:ca000120 (identifier)
/full/800,/0/default.jpg (region etc.)
And if we want to focus on Boulder County by cropping out the rest, the URL looks like:
https://tile.loc.gov/image-services/iiif
/service:gmd:gmd370m:g3700m:g3700m:gla00130:ca000120
/2910,1028,660,509/250,/0/default.jpg
The difference is in the last part of the URL, where a restricted region and lower resolution have been requested; the result appears on the right.
The specification requires another endpoint, of the form https://example.org/{id}/info.json, where the server must provide key characteristics about the image as well as which optional features of the API the server itself implements. Here is the info.json that the Library of Congress gives us for the above image. (This site still uses version 2 of the Image API.)
Using this API, IIIF viewer software can efficiently query the server for cropped and downscaled pieces of even extremely large image files (such as this panorama of the painting The Battle of Murten), to focus on an area of interest and to provide advanced, traffic-efficient, deep-zoom views, similar to applications like Google Maps or OpenStreetMap. (Keeping in mind that map services generally deal with rasterizing vector tiles, whereas IIIF deals with bitmaps.) Image servers are also required to advertise in the info.json which resolutions and tile sizes are available pre-rendered, so viewers may prioritize requesting those to minimize lag and the computation demands imposed on the server.
An image server with large assets can be susceptible to denial-of-service attacks. The protocol necessarily allows clients to repeatedly ask for computationally intensive image-processing operations and vary the parameters just a little bit to ensure cache misses. Servers must be deployed defensively, taking care to aggressively cache the most anticipated assets and their most requested tile sizes. Many implementors also try to fend off machine-learning bots with reverse proxies, web application firewalls, rate limits, or services like Cloudflare. It is a struggle.
Typically, when serving images over IIIF, the files are kept on disk in a format that supports storing multiple resolutions in a tiled representation, as opposed linear rows of pixels. The most popular formats are TIFF, using a special internal layout called "Pyramid TIFF", and JPEG 2000.
There are a handful of popular IIIF-compatible image servers, the most popular ones probably being Cantaloupe (University of Illinois/NCSA Open Source License) and IIPImage (GPL v3.0). The latter can handle a few other, similar protocols in addition to IIIF, plus it has features like support for multispectral images, allowing sites to keep not only multiple resolutions of visible-light photography but also X-ray or ultraviolet representations of a subject in one TIFF file.
An IIIF-compatible backend can also be implemented completely statically by simply pre-computing all the tiles one wishes to serve, along with the appropriate JSON metadata, as long as one declares the appropriate flag in that JSON announcing to clients that only these tiles may be requested.
As the Image API is quite simple, some organizations do end up creating their own server software, and some complicated digital-asset-management systems (DAMS) also support the API.
Presentations and collections
The other leg that IIIF stands on is the Presentation API, which is quite a bit more complex. It is a definition for a document that points at one or more images and accompanies them with metadata. The Presentation API is what makes a digital object whole by, for example, stitching the individually digitized pages of a book into a linear viewing experience. The metadata usually contains information about the physical original's location, authorship, publication date, whether it is part of some series, its Uniform Resource Name, and so on.
A presentation can comprise images from multiple sources. For instance, if multiple museums in different countries have incomplete, digitized fragments of a manuscript, an IIIF presentation can combine them together into a virtual whole—without ever having to download, process, arrange, or in any way re-host the files. See this demo from Biblissima in France, which is a virtual reconstruction of a 15th-century manuscript that had its illuminations cut out long ago.
If a digitized manuscript is difficult to read due to outdated handwriting, faded text, or old-fashioned orthography, an IIIF presentation can be used to non-destructively add a set of annotations, which viewer software can then display alongside the image. Annotations can even make a centuries-old book searchable on a computer, since it has been thoroughly transcribed in the metadata.
The Internet Archive has IIIF manifests for its materials, but finding them isn't obvious. For a quick demo, let's look at the digitized copy of the first issue of BYTE magazine, hosted at https://archive.org/details/byte-magazine-1975-09. Here, the string byte-magazine-1975-09 in the URL is the item ID. To get the item's presentation manifest, we need to plug the ID into another URL template to get https://iiif.archive.org/iiif/byte-magazine-1975-09/manifest.json. Note that the Internet Archive hosts both "items" and "collections"; for collections, the correct suffix is collection.json.
Next, we can grab the URL of the manifest and take it with us to any IIIF tool. For example, that magazine can be fed to the Mirador viewer, yielding a different interface to the same material.
There is a handful of other IIIF APIs that are not as widely deployed. They deal with authorization, content search, and various machine-to-machine data-ingest concerns, for example.
The IIIF metadata formats have not been designed ad hoc, but rather they build on prior art established in existing W3C recommendations and semantic foundations, most notably "Architecture of the World Wide Web" (2004) and "JSON-based serialization for Linked Data (JSON-LD)" (first draft 2012, latest revision 2020).
While this article only talks about images, and the second I in IIIF stands for "image", in actuality the framework also supports audio-visual materials. A presentation or collection can include audio and video files as well; similarly, annotations can target spatially addressed areas of interest in a static image, but they can also target temporally addressed sections in audio or video. A popular feature enabled by this is the coupling of digitized sheet music with an audio recording, so both can be studied simultaneously.
An update to the Presentation API is expected in 2026 in the form of version 4.0 which, most notably, adds better support for 3D objects. 3D is already doable in the current 3.0 spec, but the next version comes with a major rework of some core concepts that brings 3D to equal semantic footing with 2D images and audio-visual materials.
Client software
While the Image API is designed to be compatible with regular URLs displayable in any regular web context and browser, implementing a zoomable and pannable IIIF view or presentation display requires a client called an IIIF viewer; these are generally JavaScript programs embedded in web pages. Some popular ones are Mirador (Apache 2.0), The Universal Viewer (MIT license; not to be confused with another program with the same name), Clover IIIF (MIT), and TIFY (AGPL v3.0).
All of the viewers above are wrappers on top of OpenSeadragon (three-clause BSD) which actually handles fetching the tiles from the server, stitching them, and drawing them on the page. OpenSeadragon, which made its 6.0 release on February 18, is highly configurable, supporting many different rendering modes, tweaks to user controls as well as zooming and panning behaviors, and more. What the above viewers add on top is support for showing multiple images at once, overlaying annotations, displaying metadata, and implementing the behaviors specified in the presentation and collection manifests.
Not all client programs are simple viewers; some build more advanced applications on top of IIIF. One highly celebrated and quickly evolving tool is Allmaps, a platform for georeferencing IIIF-enabled digitized maps or aerial photographs.
Highlights from the 2026 Online Meeting
The 2026 IIIF Online Meeting took place January 27–29; there is a YouTube playlist of the plenary session and four rounds of lightning talks. The plenary covered IIIF Consortium and community news and provided an overview of new features in the upcoming Presentation API 4.0, followed by discussion.
To kick off the first set of lightning talks, Tom Cramer, chair of the IIIF Consortium Executive Committee, spoke about IIIF Content Commons, a project he wants to see happen that would enhance the discoverability of content. He began by outlining the technical success and broad adoption of IIIF at a wide range of institutions but also bemoaned the fact that IIIF content is still hard to find. He proposed a new initiative to develop content aggregation solutions to remedy this.
In another talk, Tristan Roddis of Cogapp showed how the company built a new system for the British Library's Endangered Archives Programme, now incorporating images as well as audio files on the same site, using IIIF. This is part of the long recovery the British Library has been undergoing since its 2023 cyber attack.
Sonia Cook-Broen, a writer at TheTechMargin, gave a talk from the more esoteric, cyberpunk end of things, providing colorful visions of coupling IIIF plus some artificial intelligence with the InterPlanetary File System (IPFS) and a decentralized storage platform called Storacha. She observed that data impermanence is a big problem on the Internet and that, while IIIF contributes to solving many problems, it does nothing for this one. She showed a demo of her prototype site, Codex Protocol, which integrates with Storacha to find cultural-heritage objects online and store them on IPFS.
Cook-Broen's site also contains the COLLECTION_EXPLORER, a search engine of sorts for discovering IIIF content.
Alexis Pantos from the Museum of Cultural History and the University of Oslo, Norway, demoed some impressive 3D visuals provided by the BItFROST platform, based on the 3D Heritage Online Presenter (3DHOP). He showed an in-progress use case where archeological artifacts had been 3D scanned in-context at excavations, then later compiled into a research environment where the objects were annotated, linked to the archaeological context, and they could even be viewed individually or virtually placed back in situ at the excavation site. At least for the lay person with no training in archaeology, this seemed impressive. He said that, currently, too many manual steps go into combining the landscape-scale scans of excavations with models of artifacts, but his group is hoping to build better tooling and find suitable representations for this relationship in the IIIF metadata.
Governed by consortium
The IIIF Consortium, formed in 2015, steers the development of the framework, hosts meetings, and moderates an online community of contributors and implementors. There is an annual in-person conference; the next one is coming up in June 2026 in the Netherlands. The consortium comprises 71 members from all around the world. Most members are academic institutions or non-governmental organizations involved with digital-humanities and cultural-heritage subjects—libraries, universities, and ministries of culture—but there are a few corporations as well.
IIIF has been around for roughly a decade and has gone through quite a few revisions but, at the end of the day, it is just a framework and a toolkit. Frameworks live and die by the people and organizations applying their creativity to make the most of them. To see what's out there, the "awesome-iiif" GitHub repo is a nice place to start. Some highlights: Zooniverse is a crowdsourcing platform for annotations and transcriptions, Canopy IIIF is a static-site generator for building IIIF-based exhibitions, and IMMARKUS is an experimental annotation platform that currently only runs in Chromium due to its reliance on some cutting-edge browser features.
| Index entries for this article | |
|---|---|
| GuestArticles | Koistinen, Ronja |