International Image Interoperability Framework (IIIF)

Todd R. Hanneken, St. Mary’s University

Pre-Publisher Research for Brill, The Textual History of the Bible
Volume 3, A Companion to Textual Criticism
Chapter 4, Science and Technology
4.1 Scientific Methodologies and Technology
4.2.1 Image Databases and Collections
Print edition will not include appendix (target word count is 1400 words)

Table of Contents


IIIF logo
Fig. 1. The IIIF logo

The International Image Interoperability Framework (IIIF, pronounced triple-eye-eff) defines a set of standards for how images and information about them can be delivered from repositories to viewers. “The International Image Interoperability Framework,”, accessed 12/22/2019. Scholars of biblical literature will encounter IIIF mostly when studying digital facsimiles of manuscripts, and the same principles apply to images of archaeological artifacts and sites.

Scholars should recognize the letters “IIIF,” the logo (see Fig. 1), and characteristic URLs (Uniform Resource Locators). A IIIF image URL will typically end in “/default.jpg,” preceded by a series of numbers between slashes, as in this example.,3234,736,200/full/0/default.jpg
The URL of a IIIF manifest, which may describe the folios in a codex, will typically end in “manifest” or “manifest.json.”

If one is working with a repository (such as a museum or library, or other collection of images) that is IIIF compliant, one should know three things. First, the images can be used with any IIIF viewer, at least on a technical level. Permission to access and license to reuse may be a different question. Repositories will typically offer their own instance of one of the standard viewers (such as Mirador), and the link can be copied or the icon dragged into another viewer if the user prefers. Other viewers and interoperable tools are listed in the IIIF Awesome GitHub repository, “Awesome International Image Interoperability Framework,” GitHub,, accessed 12/22/2019. Second, more information is likely available about the image. If one is looking at a cropped portion, it is likely possible to expand the image to the full page or further to include reference objects such as a ruler. If the image is low resolution, it may be possible to increase the resolution. If the page is logically contained within a codex or other sequenced collection, it is likely possible to navigate to the other pages and see metadata about the object, such as owner, license, and date of origin. In many cases annotations may be available that provide transcriptions or describe features of the manuscript. Third, the image or collection may be reused in derivative form. The IIIF standards eliminate the need to download an image, modify the image (such as cropping or down-sampling), and upload to a new site. For example, the paleography chart of characters in the erased layer of the Jubilees Palimpsest can be a single HTML file with links to the image repository. Without IIIF such a document would be created by downloading, opening, cropping, saving, and uploading image files for each sample. “Latin Moses Paleography,” The Jubilees Palimpsest Project,, accessed 12/22/2019. Whereas an image may have otherwise existed in different resolutions for thumbnails, screen resolution, and print resolution, with IIIF a single repository can serve derivatives as needed. These derivatives can be used in new contexts without losing reference to the originating repository. In that way, IIIF provides not only convenience but attribution, something like a standard reference format for digital images. Similarly, IIIF standards allows scholars to create new collections of pages without duplicating contents. Where one might previously have wanted to download or print a PDF, extract and rearrange the pages into a new document, then upload the new PDF, IIIF and tools supporting it allow one to create a new collection from existing resources. For example, if a scholar wanted to collect in one place canon tables or incipits originally spread across various other contexts, IIIF could be an efficient way to do so. An end user might wonder why use IIIF instead of downloading, printing, cutting with scissors, and pasting with glue. The difference is important for anyone who is not truly the end user. That is, IIIF is essential for scholars and especially museums and libraries who want to share the result of the work with others in a digital format on the Internet with proper attribution.


Just as human-readable communication utilizes standards such as scripts, languages, genres, citation formats, and style manuals, machine-readable communication also uses standards. Computers sometimes use artificial intelligence to understand communication designed to be human readable, but with a low degree of reliability. Standards designed for machine communication are called Application Program Interfaces (APIs). IIIF defines standards that are readable to machines and also (with some effort) to humans. Human can rely on machines to provides a graphical user interface to the information communicated by way of IIIF standards, but it is sometimes helpful to understand the mechanics “under the hood.” IIIF defines standards for interoperability so that machines can share information with machines and, as appropriate, with humans. The standards most important for biblical scholars are the Image API, which standardizes communication about images and parts of images, and the Presentation API, which standardizes communication about collections of images. In addition to these, the Authentication API provides a method for restricting access, when necessary, and the Search API provides a method for discovery of information about collections of images.

Image API

The Image API describes ways that images can be requested and shared. “Image API 3.0,” International Image Interoperability Framework,, accessed 12/22/2019. It is least helpful when a user wants a full image at full resolution without modification. It is most helpful when only a partial region (such as a detail) or partial resolution (such as a thumbnail) is needed. In those cases only the needed information is transmitted, which can save time and resources compared to sending the full image size and resolution whenever any part thereof is needed. An analogous use case is Google Maps, which loads only general information about a region on an initial view, and then loads more information about a narrower region upon zooming in, or less specific information about a wider region upon zooming out. When detail regions of an image are transmitted between machines they are called “tiles.” Naturally, humans also have use of showing detail regions of an image as quickly as possible. For an example of how the IIIF Image API can be useful for text-critical scholarship, see the online appendix. T.R. Hanneken, “Appendix: Example of How the IIIF Image API can be Useful to Text-Critical Scholarship,” International Image Interoperability Framework for Brill THB,, accessed 12/22/2019.

Presentation API

The IIIF Presentation API expresses the relationships images have with other images, annotations about those images, and larger abstract or physical constructs. “Presentation API,” International Image Interoperability Framework,, accessed 12/22/2019. The language of the Presentation API can be unwelcoming in as much as it is generalized. For scholars of biblical literature, the following terms from the IIIF Presentation API typically have specific examples among biblical manuscripts. A “canvas” will often be a page. An entire scroll could be treated as one large canvas, or individual columns or sewn segments could be canvases. A canvas may be described by many images, either next to each other (as with assembled fragments) or on top of each other as layers (as with different multi-spectral processed images. An “annotation” can be any additional information about a canvas, such as transcriptions or notes of scribal features. Technically an image is an annotation that describes a canvas. A “manifest” will typically represent a codex or scroll but could be a single canvas. It often represents a “real world” object, but could collect images on thematic principles. A manifest is a file (in JSON format) that includes canvases, annotations, and other metadata. Scholars will most often encounter a IIIF Presentation as a URL, such as:

A IIIF Presentation manifest is more likely recognized from context than any distinctive required feature of the URL.

A scholar might encounter a IIIF Presentation manifest in a library catalog or other website. Once a scholar has the URL of a IIIF Presentation manifest, there are three things that may be done with it. First, the manifest can be opened in any IIIF viewer, such as Mirador. Libraries and repositories will often offer their own instances of an open-source viewer, but with features disabled or less desirable configurations. More importantly, a scholar can open manifests from multiple repositories in single viewer for side-by-side comparison. Second, a scholar can read and search the manifest in a web browser for information hidden in an interface such as Mirador. For example, a viewer may replicate the ability to zoom and rotate discussed in the online appendix, but it does not (currently) provide the user with a URL of an image in the IIIF Image API. T.R. Hanneken, “Appendix: Example of How the IIIF Image API can be Useful to Text-Critical Scholarship,” International Image Interoperability Framework for Brill THB,, accessed 12/22/2019. Such a URL would be useful to share the image with others as a link in an email, document, or webpage. Third, a moderately advanced scholar, even without learning all the rules of Presentation API, should be able to copy canvases from multiple manifests into a new manifest to collect (and share) a sequence of images important for scholarship and teaching.

IIIF History, Consortium, and Community

In September 2011, a Scholarly Communications grant from the Mellon Foundation to Stanford University propelled IIIF from earlier work by Digital Medieval Manuscripts (DMS Tech) into an international collaboration with Bodleian and British Libraries. “Grants Database, International Image Interoperability Framework,” The Andrew W. Mellon Foundation,, accessed 12/22/2019. “The International Image Interoperability Framework (IIIF): Laying the Foundation for Common Services, Integrated Resources and a Marketplace of Tools for Scholars Worldwide,” Coalition for Networked Information,, accessed 12/22/2019. The IIIF Consortium was founded in 2015 by eleven institutional members (mostly libraries) to sustain and develop the technology and community around IIIF. “IIIF Consortium,” International Image Interoperability Framework,, accessed 12/22/2019. Tom Cramer, “News, IIIF Consortium Formed,” International Image Interoperability Framework, 6/17/2019,, accessed 12/22/2019. The IIIF Community is active and open on Google Groups, conference calls, and Slack. “Community,” International Image Interoperability Framework, accessed 12/22/2019. “IIIF-discuss,” Google Groups,!forum/iiif-discuss, accessed 12/22/2019.

Appendix: Example of How the IIIF Image API can be Useful to Text-Critical Scholarship

An overview of what is standard and typical in a IIIF Image can be seen from an example from the Jubilees Palimpsest Project. All of these examples are real and can be seen by opening the link in a web browser.,3234,736,200/full/0/default.jpg

“http://” defines the protocol for transferring information across the Internet. Also common is “https://.” “jubilees” is the name of the server for the Jubilees Palimpsest Project. “stmarytx” is the domain of St. Mary’s University in Texas, the host of the project. “edu” is the top-level domain for educational institutions in the United States. Slashes “/” separate path elements, starting in this case with “iiif.” The path does not necessarily correspond to a file path on the server operating system. In most cases the path is directed to dynamic image server that generates the indicated image on demand. However, the path could be a file path on the server operating system. One might want to do this if a certain thumbnail or other tile was so frequently requested that it would be a better use of resources to store it as a static tile than to generate dynamically anew for each request. It is not required but it is common to include these letters in paths compliant with the IIIF Image API. The format of the image identifier is not standardized by IIIF. The Jubilees Palimpsest Project uses the convention of “Owner_Shelfmark_Page_ColorProcess_LightPosition.jp2.” That is, Biblioteca Ambrosiana manuscript C73 inf page 67 (following the modern pagination). “Ac” signifies accurate color, as opposed to enhancements from spectral imaging. “00” signifies diffuse reflected light, as opposed to an integer such as “55” for raking illumination or “Tx” for transmitted illumination (backlighting). “.jp2” indicates that the repository stores the image in the Jpeg2000 format, which allows lossless compression and facilitates quick access of only the region and resolution required.

After the identifier, the IIIF Image API specifies exactly what may appear in the path. First is the region. In the example given, the region starts 3378 pixels from the left side and 3234 pixels down from the top. The region itself is 736 pixels wide and 200 pixels high. The next path element is the resolution. For this relatively small region a web browser can easily show its “full” resolution (“max” in version 3.0). The next path element is rotation, here zero for no rotation, and often limited to 0, 90, or 270. “default” refers to the image quality, which can be somewhat misleading. There are many things a scholar might want to know about the quality of an image, but this path element only tells us that it is not down-sampled to grayscale (which could be useful in print publications). Finally, “.jpg” is the format in which the image is delivered from the repository to the viewer. Unfortunately, there is no way to know the level of lossy jpeg compression applied at the server, and lossless formats such as PNG are not currently required by the standard. Together, the IIIF Image API specifies a URL that preserves important information about the image referenced, its source, and the particular region. In that way, the IIIF Image API can be thought of as a stable reference format for images, not unlike Chicago Manual of Style does for scholarly reference to the origin, title, and specific location (page) within a print work.

The joy of the IIIF Image API is not just that the URL of an image is standard and human-readable, but that it can be modified. The example given is a detail from the Testament (or Assumption) of Moses, a work originally in the same codex as another work attributed to Moses, the Book of Jubilees. The detail is of the name of an eschatological figure, read as “Taxo” by the 1861 editor and unquestioned for a century and a half. A.M. Ceriani, Fragmenta latina evangelii S. Lucae, parvae genesis et assuptionis Mosis, Baruch, threni et epistola Jeremiae versionis syricae Pauli telensis cum notis et initio prolegomenon in integram ejusdem versionis editionem (Monumenta Sacra et Profana ex Codicibus praesertim Bibliotheca Ambrosiana 1.1; Milan: Typis et impensis Bibliothecae Ambrosinae, 1861). It is not an otherwise known name and likely represents a number value (gematria). The IIIF Image API allows us to study this reading right in the web browser simply by modifying the URL in the browser address bar. First, we might want a look at the whole page for context. We could modify the region to “full” (“max” in version 3). Since the full image is fifty megapixels, we could save resources by requesting only the resolution that could be displayed on screen, in this case ten percent of the full resolution.

We could also get a much better feel for the condition of the folio by changing the light position to a raking angle of illumination.

The region in question is clear enough in the first, second, and fourth letters, but the third is ambiguous. If it is an “X” as read in 1861, it is unusual in how low the strokes cross. An “A” differs from an “X” in that the ascending stroke loops back down to the lower left, rather than continuing to the upper right (see the second letter). We do see a mark in the upper right, but the text is a palimpsest overwritten with another text “upside down.” We could read the upper text more easily by changing the rotation.,3234,736,200/full/180/default.jpg

Indeed the “a” between the “s” and the “e” on the top layer could account for the mark that would differentiate an “X” from an “A” on the bottom layer. We could differentiate between the inks of the two layers with multi-spectral image processing. In this case, we could switch from Accurate Color (Ac) to the first enumerated image produced by scientist Roger L. Easton, Jr. (RLE01). The existence of such a color process variant would only be known from consulting a Presentation API manifest.,3234,736,200/full/0/default.jpg

The enhanced images available cannot conclusively determine that the letter can only be one or the other. Philologists will have to decide if “Taao” could make more sense than “Taxo.”