Dezoomify rebuilds museum images from the tiles behind the viewer

It starts from a description file, not from the picture

Dezoomify finds the full image behind a zoomable viewer and assembles its tiles into a picture you can save, and the README is clear that it works with image viewers used by museums, libraries, archives and map collections.

The mechanism starts with a description file. Zoomable image technologies are all built on the same idea, a manifest that lists the tiles and where they live, and Dezoomify supports IIIF, Deep Zoom, Zoomify, Google Arts and Culture, krpano and other formats. If you already have the address of the description file, such as an info.json, an ImageProperties.xml or a .dzi file, you can paste that directly instead of the viewer page, which removes a layer of guessing.

That distinction explains the tool's limits better than any feature list. The README says plainly that no app works with every website, because a site that does not use a recognised tile protocol has nothing for Dezoomify to read. It is not crawling and reverse engineering arbitrary galleries; it is a client for a family of published image APIs, and it is good at exactly the sites that implement one of them.

The project is primarily Rust, licensed GPL-3.0-or-later, and its homepage is dezoomify.ophir.dev. A legacy version of the website is still hosted alongside the current beta.

Four front ends, and each one has a different ceiling

The same codebase runs on several platforms with different capabilities, and the README describes each honestly, including where it is weakest.

The website is the easiest to run and the least powerful. Nothing to install, you paste the address of the image page. Some websites block it, it cannot use your browser login, the browser limits the maximum image size so it may save a smaller resolution than the source offers, and it saves PNG files.

The browser extensions for Chrome and Firefox work on sites where you are signed in, and they work around some restrictions that prevent the website itself from saving images. They also find image addresses hidden behind the viewer, through a Dezoomify button in the browser toolbar. They share the browser's final image size limits.

The desktop app for Windows, macOS and Linux saves larger images, opens local files, and supports PNG, JPEG, TIFF, ZIF, WebP and IIIF tile folders. Interrupted saves can resume using cached tiles. Its limit is your available memory.

The command line tool gives the same saving capabilities as the desktop app but for scripts, with the ability to choose a particular image or zoom level, limit the resolution, or save a list of addresses with --bulk.

The rule that falls out of this is simple. Need a signed in session, use the extension. Need the largest file or need to script it, use the desktop app or the CLI. Everything else, use the website.

Running the CLI, and the build steps behind it

The command line tool is distributed in a dezoomify-cli archive on the releases page as a Linux x86_64 executable, and it can be built from source.

The build and contribute section asks you to install Rust and the Node.js version pinned in .node-version, then run a set of commands from the repository root.

cargo xtask setup
cargo xtask check
cargo xtask test
cargo xtask dev web

These are custom cargo subcommands provided by the crates/xtask member of the workspace, which is a common Rust pattern for wrapping project tasks behind a single interface. setup prepares the workspace, check and test run the verification steps, and dev web starts the web front end for local development.

To build the command line tool specifically, the README says to run cargo xtask build cli, and the resulting executable is target/debug/dezoomify-cli.

target/debug/dezoomify-cli "https://museum.example/collection/painting" painting.png

The interface is a URL and an output path, which is what makes it scriptable. The --bulk option takes a list of addresses, so a batch of museum pages can be processed unattended.

The desktop installers are published as .msi for Windows x86_64, .dmg for Apple silicon Macs and .deb for Linux x86_64. The README is explicit that they are unsigned, so your operating system may ask you to confirm that you trust the installer, and it points to Help and Check for updates inside the app, which installs a signed update after you confirm.

A Rust core with a WebAssembly twin and a React front end

The workspace in Cargo.toml shows how the pieces fit together, and it is a more informative artefact than the README.

The members are crates/xtask, crates/fixture-server, crates/dezoomify, crates/dezoomify-wasm, crates/dezoomify-native, apps/cli and apps/desktop/src-tauri. So there is a core crate, a native build of it, a WebAssembly build of it, a fixture server used by the tests, the CLI application and a Tauri desktop shell. The workspace version is 3.1.0, the edition is 2021 and the licence is GPL-3.0-or-later.

The web side is a pnpm workspace with a Vite build, React 19, a shared UI package, a browser runtime package and WASM bindings. The published dependencies include a wasm-bindings package, and the devDependencies include wrangler, which is the Cloudflare Workers toolchain, and Playwright, which is how the browser extension and web front end are tested. Biome replaces the usual eslint and prettier pair, and sharp handles image work on the JavaScript side.

The Rust configuration is where the project's standards are written down. The workspace lints deny rust_2018_idioms, unused_must_use and unsafe_op_in_unsafe_fn, and the Clippy set denies cognitive_complexity, redundant_clone, match_same_arms and nonminimal_bool while allowing pedantic and nursery. A comment explains why clippy::unwrap_used is not in the workspace table, since a workspace deny would also lint integration test targets, while the policy is to deny it in shipped source and allow it in tests. There is a separate dev-debug profile for symbolic debugging, since full DWARF information makes local build artefacts much larger.

When a site refuses, and what the README tells you to do

The troubleshooting section is short and practical, and its tone is instructive rather than apologetic.

If no image is found, the advice is to try the browser extension on the page showing the image, and if that finds nothing, to follow the guide on finding the image address yourself, which is the manual path to the same description file.

If a login is required or access is refused, use the extension while signed in. If the site only serves images to its own viewer, the desktop app and the CLI can identify the viewing page in their requests, and the troubleshooting document covers forbidden and unauthorized errors.

If the image is too large, blank or impossible to save, use the desktop app, because installing the extension does not remove the browser's size limits.

And if you hit 429 responses, which means too many requests, the instruction is to wait a few minutes before trying again. That line is the clearest signal about how the project expects to be used, and it is the one most worth repeating: the tool is meant for saving images you are allowed to save, at a rate the site will tolerate.

For a site that needs support, the README asks you to search the existing issues for the site's name first, and then to file a request with the new site support template, including the exact viewing page address, the address you gave Dezoomify, which app you used, and the diagnostic report from the Technical details and logs panel.

Continuous rolling releases, and one project that keeps its secrets outside the repo

The release tags are the interesting operational detail. The three most recent are rolling-v3.1.767 from 2026-10-19, rolling-v3.1.766 from 2026-10-18 and rolling-v3.1.765 from 2026-10-17. The last push to the repository was on 2026-10-19, and the project is not archived.

A rolling tag scheme means there is a continuously updated build rather than a slow version cadence, which fits a tool whose supported site list changes as sites change their viewers. The cost is that there is no long lived stable version to pin, so an installation tracks whatever the release channel currently serves.

The .env.example file shows a project that takes its operational hygiene seriously. The Chrome Web Store API credentials are documented as a template only, with the OAuth client JSON living outside the repository at a path under the user's config directory with mode 600, and only the refresh token and an optional extension ID override going into a local .env. The file states that real values must never be written into any committed file, and it points at a one-time authorization script under the extension's scripts directory.

It also records that the extension ID is public and fixed, read from release/config.toml, with an emergency override available and a warning never to create a new store item. The loopback port for the OAuth flow defaults to 8085, with a note that Google accepts any 127.0.0.1 port without pre-registration. That is a small, well documented piece of release engineering.

When Dezoomify is the wrong tool

Three cases rule it out.

The first is a site that already offers a download. Many museum collections provide a full resolution file or a print order, and using that is faster, more polite and gives you the best available image. Dezoomify is for the sites that only offer tiles.

The second is a site whose terms forbid it, or an image you have no right to save. The tool is aimed at openly licensed museum and archive images, and the rate limit guidance in the README is only sensible under that assumption. Nothing in the project should be read as advice on reaching files you are not entitled to.

The third is a collection of images in one format, where a dedicated tool would be better. If you are pulling a thousand items from a single IIIF server for an archive, writing a small script against the IIIF API gives you more control over requests, and it avoids the browser size ceiling entirely.

Within its scope, the multi front end design is the real strength. The same Rust core serves the site, the extension, the desktop app and the CLI, so a site supported in one is supported in the others, with the differences between them being about limits rather than about capability.

Editorial conclusion

Dezoomify fits a researcher or archivist who needs the highest resolution copy of a public museum image that the site itself only offers as tiles, since it supports the main tile protocols and can save PNG, JPEG, TIFF, ZIF, WebP and IIIF tile folders. It is the wrong choice when the site already offers a download button, when the image is behind a login you do not have rights to, or when you need a signed installer on a locked down desktop. Before adopting it, check that your target site uses one of the supported formats, and if a site returns 429 responses, back off rather than retrying, because the README treats rate limiting as a normal condition rather than an error to route around.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. lovasoa/dezoomify on GitHub
3. Project website
4. README
5. Releases