A beginner’s guide to MIME types in archived web files

When an old website is preserved, the visible page is only one part of the record. Images, stylesheets, audio clips, PDFs, downloadable documents and compressed folders all carry information about what they are. That information is expressed through MIME types, also called media types. Understanding them makes it easier to inspect an archive, diagnose broken links and preserve files in a form that remains useful.

For anyone exploring a historical website, MIME types provide a practical bridge between the original server and the saved material. A browser in Brisbane, Perth or Canberra may display an archived page differently from the way it appeared years ago, especially when a server rule, file extension or character encoding has been lost. Learning the basics helps visitors distinguish missing content from content that has simply been served incorrectly.

What a MIME type tells a browser

A MIME type identifies the format of data being transferred. The name has two parts separated by a slash: the broad category comes first, followed by the specific format. For example, text/html describes an HTML page, text/css describes a stylesheet, image/jpeg identifies a JPEG image and application/pdf identifies a PDF document.

The original web server usually sends this information in an HTTP response header named Content-Type. A simplified response might contain Content-Type: text/html; charset=UTF-8. The first part tells the browser what kind of file it has received, while the optional charset declares how text should be decoded. If a page contains Australian place names, curly apostrophes or older character symbols, the charset can determine whether they display correctly.

A file extension is useful, but it is not the same thing as a MIME type. A file called newsletter.pdf may be sent as application/pdf, while a misconfigured server might send it as text/plain or application/octet-stream. Archives often retain the extension but lose the original server header, so both clues need to be considered.

Common media types in website archives

HTML pages are commonly labelled text/html, and plain text files use text/plain. CSS files generally use text/css, while JavaScript may appear as text/javascript or, in older material, application/javascript. These labels influence whether a browser interprets a resource as code, displays it as text or offers it as a download.

Images have their own families of types, including image/png, image/gif, image/jpeg, image/svg+xml and image/webp. A preserved site may contain several generations of image formats because web design changed quickly. A small GIF logo from the early 2000s and a later SVG icon can sit in the same directory, even though they were created for very different browsers and connection speeds.

Documents and compressed files are equally important. PDFs usually use application/pdf; ZIP archives use application/zip; and common audio and video formats include audio/mpeg, audio/ogg, video/mp4 and video/webm. Some older or unusual formats have less consistent labels. In those cases, a file inspection tool can examine the opening bytes, often called a magic number, rather than relying on the name alone.

Why archived files sometimes behave strangely

A web archive may store a page and its assets separately. If the saved HTML refers to /images/logo.gif, the archive must locate the corresponding image capture and rewrite the path or emulate the old URL. A missing capture can appear as a broken image, but an incorrect media type can create a different problem: the file may download instead of displaying, show as plain text or trigger a browser warning.

Compression adds another layer. Web servers can apply HTTP content encoding, such as gzip or Brotli, to make transfers faster. This is different from the MIME type. Content-Type describes the underlying resource, while Content-Encoding describes how that resource was compressed during delivery. An archive viewer that confuses the two may present compressed bytes as if they were an HTML document.

Older servers also used broad defaults. If a host did not recognise a file extension, it might return application/octet-stream, a general binary label. That does not mean the file is damaged. It means the browser has been told to treat it as an unspecified download. Renaming the extension based on reliable evidence can help with local inspection, but changing the original preserved copy would remove useful historical evidence.

A practical example can be found when browsing a preserved article that links to an external resource. An archived page may contain a saved HTML shell while the linked material was captured under a different path or not captured at all. A record such as the roulette strategy story can illustrate why the link destination, file extension and returned media type should be checked independently.

Reading headers and file extensions together

If you can access the raw response, inspect the Content-Type header first. Browser developer tools usually show it under the Network panel, while command-line utilities such as curl -I can request headers without downloading the complete file. A response may reveal a useful combination such as Content-Type: image/png, Content-Length, Last-Modified and caching information.

When the archive is available only as downloaded files, compare the extension with the file signature. A PDF normally begins with characters such as %PDF, a ZIP file begins with a ZIP signature, and common image formats have recognisable opening bytes. Utilities such as the Unix file command, desktop metadata viewers and archive-management software can help identify content without opening it in a browser.

There are limits to this method. Some formats are containers that can hold several kinds of content, and a web page may have been generated dynamically rather than saved as a single complete file. A .php extension, for instance, describes a server-side script name rather than the format delivered to a visitor. The result might have been text/html, JSON or a file download, depending on the request.

For a clean record, preserve the original filename, capture date, source URL and any available response headers. Make a separate working copy for repairs or conversions. This approach is useful for a long-running resource hub such as Papajohnphillips archive, where navigation, historical context and preserved files may matter as much as the appearance of an individual page.

Character sets, downloads and browser safety

MIME types can include parameters that affect interpretation. The most familiar is charset, as in text/html; charset=UTF-8. UTF-8 is now common, but older pages may have used Windows-1252, ISO-8859-1 or another encoding. If the wrong charset is applied, quotation marks, accented characters and symbols can turn into garbled text even though the underlying bytes are intact.

Some responses include Content-Disposition: attachment, which tells the browser to download a file instead of displaying it inline. This is common for office documents, software installers and data exports. An archive may preserve the file but omit that header, causing a PDF to open in a tab, or add it incorrectly, causing an HTML page to download.

Security headers also affect archived browsing. A modern browser may refuse to run an old script because of a restrictive content security policy, mixed HTTP and HTTPS resources or an unsafe file context. Active content deserves particular care: do not run unknown executables, macros or scripts merely because an archive labels them as a familiar type. A MIME label is a declaration, not a guarantee that the content is safe.

Australian users may encounter these issues while viewing older material on a mobile connection, where a browser’s automatic download behaviour can consume data or fill a phone’s storage. On a home NBN connection, the transfer may feel instantaneous, but the underlying distinction between a displayed resource and a downloaded attachment remains the same.

Preserving a reliable record for the future

Good preservation begins with provenance. Record where a file came from, when it was collected, which archive service supplied it and whether it was altered. Keep original response headers when possible, along with checksums such as SHA-256 for downloaded files. A checksum does not explain a file’s format, but it can show whether the preserved copy changed later.

Legal and ethical boundaries should be documented as well. In Australia, copyright is governed federally under the Copyright Act 1968, and copying an old web page for preservation does not automatically remove the rights attached to photographs, articles, music or software. A responsible archive should distinguish between material available for private research and material that may be republished publicly.

Privacy deserves attention because historical pages can include names, email addresses, photographs or community notices that were once easy to find but are now being resurfaced. The Australian Privacy Act 1988 may be relevant to organisations handling personal information, while practical stewardship also means reviewing whether sensitive material needs to be displayed in full. MIME metadata does not settle these questions, yet it helps identify what kind of file is being handled and where it may be embedded.

Domain and hosting arrangements also form part of the record. A .au domain, a registrar account and an archive export may be managed by different parties, so keep administrative notes separate from public content. Clear folders, stable filenames and a short README can help a future maintainer understand why a file is labelled application/pdf, why another is stored as raw binary and which pages depend on each asset.

A simple workflow for beginners

Start by saving the page and its associated resources without overwriting the original download. Note the URL, date and archive source. Open a copy in a text editor to inspect HTML references, then list linked assets such as CSS, JavaScript, images, fonts and documents. Missing files can often be identified by comparing those references with the archive’s captured paths.

Next, check the apparent type in three places: the filename extension, the response header and the file signature. If all three agree, the item is probably straightforward. If they conflict, preserve the original and record the disagreement. A file named .jpg with a PDF signature should not be casually renamed and treated as an image.

For pages that use scripts, test a static version first. Many archived sites work better when JavaScript is disabled because the original code may request live APIs, advertising services or domains that no longer exist. A stylesheet may also refer to a font or background image that was never captured. These failures do not necessarily indicate a bad HTML file; they may reflect an incomplete historical snapshot.

Finally, write a short inventory in plain English. Include each filename, likely format, MIME type, encoding where relevant, capture source and any action taken. Reviewers who encounter the collection years later will then be able to understand both the visible page and the technical decisions behind it. Further background on maintaining older web material is available in early web design lessons.

Use MIME types as clues rather than absolute truth. Preserve the original files, compare headers with signatures, document uncertainty and separate technical repairs from historical evidence. When you browse the preserved materials on papajohnphillips.com, keep a small record of what you find and share responsibly so that the site’s local stories, documents and design history remain understandable for the next reader.