Preserving a digital artwork

Reviewed on 1 October 2026. Expanded and verified on 11 October 2026. If you find an error, contact me.

A digital artwork can disappear without anyone touching it. A format may stop opening, a program may change, a service may shut down or the only valid copy may be lost. Preserving it is not just a matter of saving files: it means keeping the ability to identify it, check its integrity and show it again without altering what defines it.

What kind of work you have

Each work depends on different elements:

A file, such as an image, a video or a sound, depends on its format, its metadata and the media where it is kept.
A software work also depends on the code, the libraries, the operating system, the peripherals and the runtime environment.
A networked work may depend on a domain, a server, a database, an API or information produced by third parties.
A digital installation may include screens, projectors, sensors, cables, equipment and a spatial arrangement that cannot be separated from the experience.
A token-linked work ties that token to metadata and, usually, to a file hosted off-chain. The guide How OBJKT works explains that separation.

Before choosing a strategy, identify which components are essential and which can be replaced.

Keep more than the final file

Keep:

the master file and the published or exhibited version (the difference between the two is explained below);
the source code, where it exists;
the libraries, dependencies and versions used;
fonts, plug-ins and resources needed, respecting their licences;
metadata, titles, dates and inventory number;
installation and operating instructions;
photographs or video of the work running;
the artist's decisions on acceptable changes;
contracts, licences and acquisition documents.

A video of the work running does not replace the work, but it can document its behaviour if the original environment is no longer available.

The names in that list refer to different things. Separating them makes it possible to decide what is protected and what is replaced.

Source, master, exhibition copy and derivatives

These four categories are a working proposal, not a standard. They help whoever opens an artwork’s folder to know what must be protected, what can be replaced and what can be regenerated.

Source file. The material the work was produced with: editable project, code, layers, sequences, models, data and working versions. It may contain discarded alternatives. Keeping it makes future intervention possible, but it does not turn it into what should be delivered or exhibited.

Master. The stable copy of a version the artist has approved, identified and set apart from day-to-day editing. All other copies derive from it. In a software work or an installation, the master may be a set (executable, dependencies and configuration) rather than a single file.

Exhibition copy. The version prepared for specific equipment and conditions: it may be compressed, transcoded or packaged. It is generated from the master and can be replaced when the installation changes, within the limits the artist has set (see ‘Technical change, artistic version or new work’).

Derivatives. Thumbnails, press images, excerpts, screenshots and videos of the work running. They serve to identify and communicate the work. They do not replace the master, nor the execution of the work when it depends on interaction, duration or behaviour.

This separation is my own criterion: none of the sources consulted proposes it under these names. What museums do show is that they are not satisfied with the final file. The Guggenheim’s acquisition checklist for computer-based artwork with an artist-provided computer, which the document itself presents as a starting point subject to case-by-case evaluation, indicates that the museum should seek to obtain the original source code (or, if the work was created in a proprietary environment, the project files), complete copies of the libraries and plug-ins used, written installation and start-up instructions, and video or audio documentation of the work running. This is that museum’s practice for that type of acquisition, not a general obligation.

Copies in independent places

A common rule of thumb is the 3-2-1 rule: keep at least three copies, use two types or storage environments and keep one copy in another location. It is a practical reference, not a guarantee. For a digital artwork, each copy must contain the full dossier (sources, master, dependencies, documentation and checksums), not just the master. The copies must be independent: automatically syncing an error or a deletion across several devices is not the same as having a recoverable backup.

Also check who controls each account, how access is recovered, how long the service lasts and in what format it lets you export files.

Integrity: checksums

A checksum is a fingerprint calculated over the sequence of bits in a file. If the file changes, its checksum normally changes. Comparing a new checksum with a reference value at regular intervals makes it possible to detect alterations or corruption.

A checksum does not, on its own, prove authorship, authenticity or provenance. Nor does it show which part of the file changed. To make it useful, keep the reference value, the algorithm used, the date and its link to the file received or created. If one copy fails, another copy whose integrity has been checked can be used to replace it.

Those checksums, like everything else you have gathered, need a place and a description of their own.

One folder per artwork and a README

Gather all of the above in a folder named with the artwork’s inventory number. This minimal structure is an example, not a mandatory model:

ID-OBRA/
  README.txt
  fuentes/
  master/
  exhibicion/
  dependencias/
  documentacion/
  derivados/
  sumas/

What matters is not the names but that a person outside the process can tell what to protect, what can be run and what can be regenerated. The sumas/ folder holds the manifest with the checksums and the algorithm used. The Digital Preservation Coalition, in its digital preservation handbook, mentions as possible places for checksums a PREMIS record, a database or a manifest that accompanies the files.

The README guides; it does not replace the master artwork record or the change log. Cornell’s data management guide, written for research data, recommends writing it in plain text, avoiding proprietary formats where possible, using ISO 8601 dates (YYYY-MM-DD) and keeping the same order and terminology across all the READMEs of a project. Applied to an artwork, as my own editorial criterion, it should state:

inventory number, title and approved version;
what each folder contains and how the master and the exhibition copies relate to each other;
required software and equipment, with their versions;
minimal opening or installation instructions, with a pointer to the full document;
date of last modification and person responsible;
where contracts and confidential documentation are kept.

Credentials deserve a separate warning. The Guggenheim’s acquisition checklist for computer-based artwork with an artist-provided computer includes, among what the museum seeks to obtain in that procedure, ‘Any usernames or passwords necessary to set up or administer the computer’ and, according to the text, those for other aspects of the work, where applicable.

My own recommendation: do not store credentials in the README or in shared files. Record that they exist, who holds them and the authorised procedure for accessing them.

Each copy must include the complete folder, with README and checksums, not just the master. If the work is delivered, shared or lent, contracts, prices and buyer details do not travel inside that folder.

Formats and versions

Keep the original file even if it depends on proprietary software. Where possible, also keep a version in a well-documented, widely adopted format with no technical restrictions that prevent its use.

The Library of Congress’s Recommended Formats Statement offers preferences by content type. It distinguishes between ‘Preferred’ and ‘Acceptable’ formats according to seven sustainability factors: disclosure, adoption, transparency, self-documentation, external dependencies, patent impact and technical protection mechanisms. It is designed for published works, also applies criteria specific to the Library’s own resources and, according to its introduction, gives no instructions for receiving or managing content. It cannot by itself decide which format best sustains a particular artwork.

Do not convert or overwrite the only original. Document each migration, keep the previous version and compare image, sound, duration, colour, interaction and metadata.

How to name, number and record those versions is explained below.

File names

A working document from the United States National Archives and Records Administration (NARA), aimed at agencies establishing naming conventions for electronic records, sets out its guidance: file names should use only the letters a to z, the numbers 0 to 9, underscores and hyphens; they must not contain spaces or more than one dot. These guidelines are intended for those records, not a general standard. Adopting them for an artwork is my own decision and reduces the risk of names that are incompatible between systems. Applied literally, a letter with an accent or an ñ must be replaced (exhibicion, not exhibición).

One possible convention, my own, that respects those guidelines:

ID-OBRA_master_v02.mov
ID-OBRA_exhibicion_v02.mp4
ID-OBRA_instalacion_v01.pdf

Replace ID-OBRA with the identifier you already use in your inventory.

Start with the inventory number, as the master artwork record already proposes for identification photographs. The file’s function follows, then the version number with two digits. Avoid v2.1: the second dot breaks the single-dot rule.

As to what to put in the name, the sources differ. James Cook University accepts that including initials, date and status alongside the version number helps identify the file, but warns that it can become cumbersome and recommends recording that information in a control table. CESSDA’s Data Management Expert Guide accepts either version numbers or dates in the name as a system and warns against ambiguous descriptions, such as a file called ‘MyThesisFinal’. Both were written for research data and are applied here by analogy. My own recommendation: version number in the name and date in the change log. Words such as final or definitive do not say which version it is.

Versions and change log

CESSDA recommends identifying versions with a systematic convention (numbers or dates), documenting what changes were made in each one, deciding how many versions to keep, which ones and for how long, and keeping the originals or the documentation needed to reconstruct them; it also suggests including a version history table within the file itself. James Cook University proposes a control table with the version number, who modified the file, what changed, the date and the status (with examples such as draft, reviewed and final), and a single place for milestone versions and master versions. Both guides were written for research data, not for art, and are applied here by analogy as an editorial criterion. The Guggenheim, in its acquisition checklist, indicates that the assets needed to run the work should ideally be under a version control system such as Git.

A table of my own, adapted to an artwork:

Version	Date	Files affected	Reason	Person responsible	Condition
`v01`	2026-03-02	`master/`, `exhibicion/`	Initial version	Artist	Approved
`v02`	2026-09-14	`exhibicion/`	New codec for the gallery player	Technician	Migration

For the statuses, a proposal of my own: draft (may change), approved (the artist recognises it as a state of the work) and migration (a copy produced for another format or environment). Only an approved version generates a master.

The automatic history of a cloud service does not replace this log. James Cook University also recommends checking how long the service keeps those versions. Save the table in documentacion/ and copy the current approved version into the README, so that both match.

Technical change, artistic version or new work

No source consulted fixes where one change ends and another begins. What follows is my own editorial judgement and, ultimately, a decision for the artist or, if the work has been transferred, for what has been agreed.

Technical change. It modifies the file or the environment without altering what the artist has declared essential: re-encoding a video, replacing a player, updating a dependency. It is noted in the change log and produces a new exhibition copy or a migration. It does not create an artistic version.

Artistic version. It changes the behaviour, duration, composition, image, sound, interaction or any other property the artist considers constitutive. The artist decides it. It generates a new approved version, a new master and the preservation of the previous one.

New work. It is whatever the artist decides to treat as distinct. It receives its own inventory number and master artwork record, with a reference to the work it starts from.

If the artist has not said what may change, note the doubt and do not overwrite anything. It is the same question that ‘How it should be shown again’ starts from: what can change without it ceasing to be this work. If the work has already been sold or transferred, check which technical copies and migrations were authorised; Buying digital art deals with that contractual authorisation.

Relationship with the master artwork record and the inventory

The master artwork record and this folder serve different functions. The record logs which files exist (name, format, version and location) and requires distinguishing the master file, the exhibition copy, the documentation and the software needed. The folder contains them. The record has no column for checksums or technical dependencies, and provides for adding them ‘to the field or to a linked document’: that document can be the manifest in sumas/ and the README, linked by the inventory number.

To avoid duplicating data that would later diverge, the record points to the folder and the README repeats only what is essential (inventory number and approved version). Update the record when a new version is approved or a migration is made, just as the record asks to be updated after each exhibition, deposit or transfer. Contracts and confidential data are kept outside the folder, linked by that same number, as the record proposes.

As for copies, the guide How to document the provenance of your own work recommends keeping at least three: the working copy, another physically separate, and an external or remote one, and checking that they open. This is the same basis as the 3-2-1 rule in this guide. For a digital artwork, each of those copies must contain the full dossier.

How it should be shown again

For a software work or an installation, describe:

operating system and versions;
resolution, aspect ratio and colour profile;
equipment, screen, projector, speakers or sensors;
spatial layout and lighting and sound conditions;
start-up, calibration and shutdown sequence;
expected behaviour;
replaceable elements;
changes that require authorisation;
known faults.

The central question is not only ‘how does it work?’ but ‘what can change without it ceasing to be this work?’

Migrate, emulate or recreate

The strategies can be combined:

Migrate: move files or components to current formats and systems. This makes access easier but may change properties of the work.
Emulate: reproduce the earlier hardware or software environment on a new system.
Recreate: rebuild the work from documentation, code, available components and the artist's instructions.

There is no universal solution. The choice depends on which features must remain and which changes the artist has authorised.

Platforms, servers and tokens

Do not leave the only copy on a platform. Keep locally the files, metadata, contracts, addresses, identifiers and transaction receipts that apply.

If the file uses IPFS, its content identifier does not guarantee that it will remain available. Nodes can delete data from their cache. To keep it accessible, someone has to store it and serve it, for example by pinning it on one or more nodes or through a pinning service. Also keep an independent copy outside IPFS.

If a service disappears, the token or identifier may remain on record while the file is no longer accessible. A permanent record is not the same as preserving the work.

When the work enters a collection

The artist should hand over sufficient documentation and the collector should keep it together with the work. It is worth identifying:

the version acquired;
the file or set of files delivered;
the reference checksums;
the rights and technical copies authorised;
the display instructions;
the dependencies and access required;
the procedure for migrating, repairing or replacing components;
the person to ask if a doubt arises.

Periodic review

Do not wait for a work to fail. Review regularly:

that all copies can be located and opened;
that the checksums match;
that accounts, domains and services are still active;
that the software can run;
that the documentation, the master artwork record and the change log reflect the current version;
that the media have not reached the end of their useful life;
that someone else can understand the system.

How often depends on the risk, the media and the complexity. Digital preservation is an ongoing process, not an operation that is completed once.

About the open conversation

This guide brings together general criteria for digital preservation. A complex work may need the combined involvement of the artist, a specialist conservator and technical professionals. If you look after digital work in a museum, an archive or a private collection and spot an omission, write to me.

Sources

Library of Congress, Recommended Formats Statement 2025-2026, introduction.
Digital Preservation Coalition, Digital Preservation Handbook.
Digital Preservation Coalition, 'Fixity and checksums'.
The National Archives, 'Checksums, DROID and software obsolescence'.
IPFS Docs, 'Persistence, permanence and pinning'.
Guggenheim, Acquisition Checklist: Computer-Based Artwork with Artist-Provided Computer. What that museum seeks to obtain in that acquisition procedure.
National Archives and Records Administration (NARA), ‘Establish naming conventions for electronic records’. Institutional guidance for electronic records.
Cornell University, ‘Writing READMEs for Research Data’. Research data management practice, applied by analogy.
CESSDA, Data Management Expert Guide, ‘Data authenticity’. Research data management practice, applied by analogy.
James Cook University, ‘Version control’. Research data management practice, applied by analogy.