On 24 December 1999, the W3C published HTML 4.01 as a Recommendation, a tidy date for a messy web. The W3C HTML 4.01 Recommendation landed in the era when table layouts, tiny image assets, embedded sound, plug-ins, and hand-managed folders became ordinary work for site makers.
That date matters because many surviving pages still carry the habits of that period. Late-1990s through mid-2000s personal sites, school pages, fan sites, saved institutional pages, and CD-ROM exports often preserve media as loose files beside an HTML document. Open one of those folders and the page starts talking before any browser loads it: a logo GIF, a JPEG gallery, a MIDI theme, a QuickTime clip, a Flash menu.
This is not nostalgia for nostalgia’s sake.
Old media files are page evidence first and playable content second. A tiny looping GIF may explain a navigation system even when the table layout collapses. A JPEG named gallery01.jpg may tell more about a local culture project than the broken thumbnail grid that once framed it. A MIDI file can mark the tone of a fan site, a school project, or a forgotten web find & curiosity that once felt perfectly normal.
Alt text: File icons for GIF, JPEG, MIDI, MOV, and SWF beside an open HTML document.
The practical move is recognition. A web archivist, writer, educator, or curious reader does not need to master every codec before making a useful first pass. They need to identify how old sites stored motion, sound, compression, and interactivity, then decide what to preserve, what to preview, and what to document without disturbing the original files.
Bottom Line: Treat the folder as a small artifact. The media files do not just decorate the page; they explain how the page worked.
Criteria for Selection
The formats here earned their place by showing up in real triage work, not by being quaint. A format stayed in the guide when a non-specialist could plausibly recognize the extension, connect it to a visible or audible page behavior, and make a safer handling decision on the first pass.
The selection favors three tests: visible cultural footprint, recurring appearance in saved site folders, and current preservation friction during migration or teaching. That is why the broader working set includes.gif,.jpg and.jpeg,.png,.mid and.midi,.wav,.aif and.aiff,.mp3,.mov,.rm and.ra,.swf, and.svg. Some belong to graphics. Some belong to sound. Some belong to video or interaction. A few sit awkwardly across categories, which is exactly why they cause trouble during archive description.
For a newsletter archive, the useful question is not “Which format is historically strangest?” It is “Which format helps explain the page to a reader today?” A restoration note for a Flash menu, a classroom explanation of MIDI playback, or a caption for a scanned postcard gallery often carries more value than a long detour into every related codec.
There is one boundary worth setting plainly. This guide supports recognition and first-pass handling, not forensic authentication or codec-level conservation. It is built for the moment when a folder lands on the desk and someone needs to understand what they are looking at before they rename, convert, or delete anything.
Field Note: Keep the original file before conversion. The extension, filename, directory location, and link reference can preserve context that a modern access copy loses.
The Classic Web Media Formats Worth Understanding
1. GIF: the small animation workhorse
GIF is the format many readers recognize before they can define it. It carried banners, buttons, badges, under-construction graphics, transparent single-color backgrounds, and looping animations across the handmade web. The format’s indexed palette limits its color range, yet that limit became part of the look: crisp little icons, hard-edged lettering, and bright decorative pieces that still read as “old web” at a glance.
A.gif file is not automatically an animation. Many old sites used static GIFs for logos, spacer pixels, badges, and navigation buttons. That distinction matters during triage. If logo.gif sits next to index.html, preview it as a branding clue before assuming it is a moving graphic. If a folder contains several tiny GIFs with names like home, next, guestbook, or email, the page may have depended on image-based navigation.
GIF also kept cultural memory unusually legible. A broken page can lose its CSS, its fonts, and its original browser assumptions, but a construction worker icon or blinking “new” badge still announces the page’s social grammar. It tells the reader that the site belonged to a world of personal maintenance, public tinkering, and visible seams.
The preservation choice is usually simple: keep the original GIF, then make an access copy only if a current publishing system needs one. Do not flatten the history out of it. A looping button can be a piece of interface logic, not just decoration.
2. JPEG: the photo compressor that made image-heavy pages possible
JPEG solved a different problem. GIF handled flat graphics well; JPEG made photographs practical for image-heavy pages. Early digital camera shots, scanned postcards, travel photos, classroom event pictures, and local history galleries often arrived as.jpg or.jpeg files because the format could shrink photographic images enough for ordinary web use.
The trade-off sits in the compression. JPEG is lossy, so it throws away image information to reduce file size. On photographs, that loss may look acceptable. Around text, sharp edges, signs, borders, and scanned illustrations, it can produce blocky artifacts, color smearing, or a faint haze that grows more obvious after repeated save-and-edit cycles.
This is where the archivist’s eye should slow down. A gallery image that looks rough may not be damaged in the archive; it may carry the scars of being edited and saved many times before it ever reached the folder. The filename can remain unchanged while the image quality quietly declines.
A.jpg extension also does not prove the file is safe or correctly labeled. Damaged downloads and renamed files can fail in modern viewers. When a JPEG refuses to open, record the filename, directory path, file size, and page reference before trying repairs or conversions. The failed open is itself a useful clue.
A Copyable Triage Workflow for One Old Media Folder
Use this exact case: a folder contains index.html, logo.gif, gallery01.jpg, theme.mid, intro.mov, and menu.swf. The goal is not to make everything play immediately. The goal is to preserve the evidence, understand the page behavior, and create a clean first-pass note that another reader could follow.
Duplicate the folder and work only on the copy. Preserve the untouched original as the evidence set. File timestamps, directory names, and original filenames can matter later, especially when the folder came from a CD-ROM export, a school server, or an old personal backup.
Open index.html as text before opening it in a browser. Look for references to logo.gif, gallery01.jpg, theme.mid, intro.mov, and menu.swf. This establishes whether the files are page assets or loose leftovers. If index.html points directly to logo.gif, that GIF probably belongs to the page’s visible identity. If it embeds menu.swf, the navigation may have depended on Flash.
Group the files by extension. Put logo.gif and gallery01.jpg in the image group, theme.mid in the audio group, intro.mov in the video group, and menu.swf in the interactive group. This quick sort reduces confusion. It also keeps the dangerous temptation away: do not start by running the most active object.
Preview the still images first. Open logo.gif and gallery01.jpg with a normal image viewer. Note whether logo.gif is static or animated, whether it uses transparency, and whether it looks like branding, a button, or a spacer-like asset. Then inspect gallery01.jpg for photographic content, scanned material, and visible compression artifacts around hard edges.
Handle theme.mid as instructions, not a fixed recording. A MIDI file is not a recording of one definitive performance; playback can change with the sound set used by the machine or software. If the source is trusted, preview it with a modern media tool and note that playback depends on the instrument set. If the source is uncertain, record the filename, extension, size, modified date, and page reference without playing it.
Inspect intro.mov only after trust is established. Treat it as video evidence tied to the page, not as a random clip. If index.html embeds or links to it, note where the link appears: splash page, gallery, lesson page, or local culture feature. That placement often explains whether the clip was an introduction, a demonstration, or a decorative multimedia flourish.
Document menu.swf without executing it first. SWF files often carried menus, intros, games, or interactive widgets. In this folder, the filename menu.swf strongly suggests navigation. Record that likely role, then check index.html for the embed reference. If the page’s main links are inside the SWF, make a note that the surviving HTML may not expose the full navigation without the Flash object.
Important: Do not rename, batch-convert, or auto-open the whole folder. Work from the copy, one format group at a time.
Here is the copyable note to leave beside the working copy: “Original folder duplicated before review. index.html references logo.gif, gallery01.jpg, theme.mid, intro.mov, and menu.swf. logo.gif reviewed first as page branding or navigation evidence; gallery01.jpg reviewed as photo or scan evidence with possible JPEG compression artifacts. theme.mid recorded as MIDI playback-dependent audio. intro.mov recorded as video pending trusted preview. menu.swf recorded as likely interactive navigation; do not execute during first pass.”
