First, have a look at the Archive uploading info. This is the public post which explains the upload procedure to our users.
Follow the existing patterns. We have a lot of precedent. When in doubt, look for the way it was done last time.
Don't move or rename files without a good reason. Archive URLs are supposed to be permanent. (See overview.)
We hate to throw away files. We're supposed to be an archive. That means saving stuff.
No live scripting in files directly accessible on the Archive. Twine games, and any other HTML with embedded scripting, should be zipped. That way they can be played via Unbox, but they don't pose a security risk to the Archive itself.
The definition of "interactive fiction" is not rigid.
Because of the UK Online Safety Act, we need to tag files that might be restricted in the UK (or, probably, other jurisdictions that pass similar laws).
You should add a safety tag to files where needed. The tag values are:
text-porn: Pornographic (sexual) content, text form.visual-porn: Pornographic content, image form.visual-gore: Violent images or depictions of gore, image form.self-harm: Content which encourages or provides instructions for suicide or self-injury.eating-disorder: Content which encourages or provides instructions for an eating disorder or behavior associated with same.unknown: One of the above tags possibly applies, but we haven't been able to verify it. (Use this for suspect items in strange formats that you don't know how to inspect.)none: Equivalent to giving the file no tags. This is only useful when dealing with tagged directories; see below.You can use more than one value, comma-separated.
Files with any of these tags will have an "interstitial page" gate. That is, when the user clicks on the file link, they will see a warning page: "This file has adult content... are you sure you want to download it?" If they hit yes, the file will be downloaded as usual.
Files with any of the tags visual-porn, visual-gore, self-harm, eating-disorder, unknown will be entirely blocked in the UK. No warning page, just an access restriction error. (Note that the UK law does not restrict text-porn.)
If you set a safety tag for a directory, the tag applies to all files in that directory (and subdirectories), unless otherwise tagged. File tags always override directory tags. To untag one file in a directory, give it safety: none.
You can use blocktree: yes/no to block/unblock all files in the directory (and subdirectories). This is equivalent to safety: unknown or safety: none at the directory level. You can use blockdir: yes/no to block all files in the directory but not in subdirectories.
Index pages (like games/twine) are not restricted at all, even if some (or all!) of the listed games are restricted. Therefore, game descriptions in the index should always be safe-for-work.
As of December 2025, we are still in the process of tagging files. Some directories entirely blocked; others are controlled by file tags. The interstitial warning page does not exist at all.
Every uploaded file lands in the Incoming directory. If it's valid, it should be moved to the Unprocessed directory. If it's spam, trash, or malware, it should be deleted.
Our current goal (as stated in the public info page) is to move files from Incoming to Unprocessed within 24 hours. We'll see if this is workable.
The procedure is:
-final-release- or -this-one-works-.Note that if there's too much data in Incoming, further uploads are blocked. (We don't advertise the exact limit, but it's measured in total file size, not number of files.) This is a good reason to move files promptly to Unprocessed.
It's pretty common for someone to upload a file and then say "Whoops, that was the wrong file, here's the right one."
My Game (correct version!).html then rename it to the intended filename. (See above.)My Game.html.1701652627.9965498, then trailing bit is a timestamp. (Sorry, it's ugly.) This is what happens if someone uploads the exact same filename twice. Use the latest version, and rename it to remove the timestamp.Deleted files go to the Trash directory. This means you can always get them back, if you don't wait too long. Trashed files older than 30 days are deleted forever.
When you edit an Index file, the old version goes to the Trash directory. So if you screw up an edit, you can get the old version back. (This is why Trash has so many files named Index-foo-bar.1.)
Similarly, when you zip up an HTML file, the original version goes to the Trash.
For most uploads, this is easy. The "suggested dir" in the file info is very often correct.
Games go in the if-archive/games subdirectory appropriate to their format. If they're not in English, there's usually a if-archive/games/format/language directory.
Development tool uploads are usually new versions of an existing tool. So you can easily find where it's supposed to be.
If you don't know where something goes, or if the "suggested dir" is clearly wrong, ask on the Slack.
HTML games in Twine, Ink, and Texture should be moved to games/twine, games/ink, and games/texture. All other HTML games should be moved to games/html.
Most of the games in the archive are organized by output format. Multiple IF dev systems may generate output files in the same output format. For example, Inform, ZIL, and Dialog can all generate Z-Code files. All Z-Code games go into if-archive/games/zcode, regardless of the dev system that was used to create them.
There are many dev systems that can generate output files in HTML format, including Twine, Adventuron, Ink, Texture, and even Inform. Unfortunately, we didn't make a very clear decision early on between whether to organize HTML files by dev system (games/twine) or by output format (games/html).
So we're going to follow existing patterns, with Twine, Ink, and Texture games in their own folders, and all other HTML games in games/html.
(Note that we always organize games/source by dev system. For example, we have separate directories for games/source/inform and games/source/dialog games. We'll continue to follow that pattern too.)
Sometimes we get two related uploads. For example, an author might upload a game file and its source code separately.
The convention is to put the game in the appropriate if-archive/games/format folder, and the source in if-archive/games/source/format. The description for each one should refer to the other. For example:
# GameName.z5
GameName, by Person.
(source code is in games/source/inform/GameName.inf)
# GameName.inf
Source code for GameName, by Person.
(the compiled game is in games/zcode/GameName.z5)
You would do something similar if a game is uploaded in two formats, or in a language translation.
An author might upload a zip file which contains the game and its source code.
In this case, you should put the file in if-archive/games/format, and then create a symlink in if-archive/games/source/format pointing to the file.
The descriptions would look like:
# GameName.zip
GameName, by Person.
Archive contains the game and source code.
(file is linked from games/source/inform/GameName.zip)
# GameName.zip
GameName, by Person.
Archive contains the game and source code.
(file is linked to games/zcode/GameName.zip)
(Here the descriptions are exactly the same, except the original says "linked from" and the symlink says "linked to".)
Fill in the description and metadata.
old) you can look at its metadata. Copy the tuid and ifwiki lines if they exist -- those will be the same for the new version.Email the user who uploaded the file, and tell them it's done. (The email address is in the file info.) Provide a link to the index page, a link to the file itself, and, if the file was zipped, the "view contents" link (for playing via Unbox). Copy submit@ifarchive.org on the email, so that the message shows up in the #ifarchive-uploads Slack channel.
A suggested email template:
To: [SUBMITTER]
Subject: [IF Archive] [GAME NAME] published on the IF Archive
CC: submit@ifarchive.org
-----
We're happy to say that your upload [ORIGINAL FILE NAME] has
been processed. You can find it in its new home at
[IF ARCHIVE INDEX ANCHOR]
The game can be downloaded directly at
[IF ARCHIVE LINK]
and you can view/play the game file online by clicking "View
contents" or visiting
[UNBOX LINK (for zipped Twine games)]
I've also updated the link on IFDB at
[IFDB LINK]
Thanks again for the submission!
[VOLUNTEER NAME]
(Volunteer for the IF Archive)
TO DO: It would be nice if the admintool had a "send email" button which filled in all of that stuff for you.
We're supposed to be an archive. That means don't delete old versions of files.
If a new version of an existing file comes in, the old version should be moved to an old subdirectory. For example, if you're replacing a game in if-archive/games/twine, the old version goes to if-archive/games/twine/old.
After moving the file to old, rename it to include the (old) version number. That way, if another new version comes in, there's no filename collision in the old dir.
After replacing an existing file, hit the "Uncache" button. This tells CloudFlare that a new version exists. (You don't have to do this when storing a new file -- only when there's an old version that CloudFlare might have cached.)
Replacing a .zip file takes a certain amount of care, because zip files are also cached by the Unbox service. The best practice is:
IFComp is a special case. The if-archive/games/competition20XX folder always preserves the games as they were released during IFComp.
The /Games subdirectory preserves the games as they were presented on the last day of IFComp. That is, mid-comp releases (before the end of voting) go in if-archive/games/competition20XX/Games. The older, start-of-comp release is moved to if-archive/games/competition20XX/Games/old.
Releases after the end of voting ("post-comp") do not go in competition20XX. We want to preserve competition20XX exactly as it was when the results came out. Therefore, post-comp releases go in the appropriate if-archive/games/format dir. (Include a line in the description saying "Original IFComp release is at ...".)
(Note that the difference between "mid-comp" and "post-comp" is about when the game was released on the IFComp web site, not when it was uploaded to the IF Archive. It's possible that a mid-comp release gets uploaded late. Check the compile date or serial number to be sure.)
(Also note that the file if-archive/games/competition20XX/IFComp20XX.zip is an exception: it is the start-of-comp package, and preserves the games as they were released on day 1. See IFTF service backups, below.)
Again, see the overview for an explanation.
You can edit the description and metadata for any file (except those in Incoming, Unprocessed, or at the root level of the Archive).
You do this by hitting the Edit Index button for the file entry. You can also hit the Edit Index button at the top of the page; this edits the description and metadata for the directory (distinct from any of its contents).
There's a separate Edit Index File button which lets you edit the entire Index file for the directory -- the directory and all its contents. This is handy for making mass changes.
As for what to put in the metadata -- follow established patterns.
Remember that Index file descriptions are Markdown. Markdown removes single line breaks. So Index descriptions will appear on the page as one long paragraph, unless you deliberately leave a blank line. (Which we usually don't.)
This is a hard question. There is plenty of fuzzy territory; lots of ways to say "Well, that is similar to stuff we already consider IF."
IFTF policy is that IFTF is not in charge of nailing down these boundaries. Most of our services are ultimately governed by (moderated) community standards: what games can be discussed on the forum, what games can be entered into IFComp, what games can be listed on IFDB and IFWiki.
That said, spam is real. If someone uploads a physics textbook or a graphical shoot-em-up game, that's probably not IF.
Reasons that lean towards an item being IF or IF-related:
None of these are rigid rules. There are always going to be people who try to game the system by uploading a file to the Archive and starting a forum thread and an IFDB entry, all at once. Raise the question on the Slack or mailing list if you're unsure.
A few services (IFComp, IFWiki, IFDB, the IF Forum) have special privileges to upload files without using the standard upload form. That means files appear in Incoming without any upload info. (If you hit the "info" link, it will say "No upload information recorded for this file.")
This should happen only for service backup files, which get archived as follows:
ifarchive/games/competitionYYYY (as is, without extracting it).competitionYYYY directory (producing the now-standard directory structure), and then discard the end-of-comp zip. We keep the start-of-comp zip permanently.if-archive/info/ifdbif-archive/info/ifwikiif-archive/info/intficforumNote that IFComp uploads do sometimes come in through the standard upload form. These are enormous, so make sure these get moved to Unprocessed right away.
Speaking of enormous...
As of mid-2025, the archive contains some 41 gigabytes of files. (Up from 37 gigabytes at the beginning of 2025, and 30GB just two years ago!) A file that adds half a gigabyte to that total is a significant bump. The marginal cost of a gigabyte is small, but if we accept large files unthinkingly, we'd be on a path to having ten times as many gigabytes pretty soon.
We should take a closer look at files that are over 1GB, and discuss them with the rest of the team. You can email the webuploaders list, or you can chat about it on Slack. Ask questions like these:
In the early days, people uploaded all sorts of IF-related content to the archive. (Back when it was an FTP site!) There was a general agreement to not upload commercial games (like Infocom game files). But we didn't really have a notion of "open-source licensing".
These days, we try to be more careful. The terms of service say:
We prefer that material be donated by the original author or someone with the legal right to accept these terms. However, we understand that some IF-related material, particularly from the early years, was distributed with no clear license or terms. We host this material as part of the common heritage of interactive fiction. If you donate work which you did not create, you warrant that, to the best of your knowledge, it may be legitimately stored and distributed by the Archive. If you are a copyright owner and wish to dispute our use of your work, please contact us. If you wish to file a DMCA takedown notice, see below
[email to dmca@ifarchive.org].
Do your best. Try to figure out whether the file was originally intended to be freely distributed. If the original author can be contacted, do that.
Very occasionally, someone asks us to delete a file. This happens rarely enough that we should pretty much always discuss it on Slack.
Ask questions like these:
It may be worth raising these issues with the requester. Do they really want the file to be deleted? Would it be okay to remove their name from the game listing rather than deleting the game entirely?
Sometimes people are confused about the difference between IFDB and the IF Archive. They may want to remove bad reviews of a game, rather than the game itself. Direct such people to IFDB.