TIFF MIME Type – Free, Online, Private

What .tiff is

TIFF is a container for one or more images plus tags. The first bytes are the byte-order mark, II for little-endian or MM for big-endian, then the number 42. An offset points at the first image file directory. Tags describe compression, which might be none, PackBits, LZW, JPEG, or something a web browser has never implemented. That is why a TIFF that opens in a print workflow displays as a broken image in a browser even when the Content-Type is correct. This page uses the .tiff extension. Map .tif to the same type if you accept it.

IANA registers image/tiff in RFC 3302. .tif is the other common extension. The media type is image/tiff. Extensions that use it on this page: .tiff. A client compares the type, not the filename, once the response has arrived. The filename still matters on disk and in Content-Disposition, which is why a wrong extension and a wrong header are two different bugs.

What sends image/tiff

What sends image/tiff: Send image/tiff for a download aimed at a print or scientific tool. Do not expect an img tag to show an arbitrary TIFF. Browser support is narrow and depends on the compression and the photometric interpretation. If the picture has to appear on a page, convert to PNG or JPEG and send that type. A scanner API can accept image/tiff and store the original, then offer a converted preview at another URL. Keep the two URLs distinct so a cache cannot swap them. The file on disk is still .tiff. Once the response exists, a client trusts image/tiff, not the filename. Because browser support is weak, a public URL with this type should send Content-Disposition: attachment when the user is downloading a scan, so the browser saves the file instead of showing a broken image icon. An API client ignores disposition and reads the type. Set both.

Content-Type for .tiff

Send image/tiff and do not add a charset parameter. The body is binary. A charset tells a text decoder to reinterpret bytes that are not text, which corrupts a download and does not help a browser sniff the format.

Content-TypeContent-Type: image/tiff

nginx, Apache, and Express

These snippets map .tiff to image/tiff. nginx reads the types block when it picks a type from the URL's extension. A location that sets default_type, or an application that sets the header itself, overrides that map. Apache AddType applies in the directory context where you put it. The Express static example writes the header for files ending in .tiff so a stale mime database in the framework cannot disagree with the type on this page.

nginx# /etc/nginx/mime.types, inside the types { } block
image/tiff                  tiff;

ApacheAddType image/tiff .tiff

Expressimport express from "express";

const app = express();
app.use(express.static("public", {
  setHeaders(res, filePath) {
    if (filePath.endsWith(".tiff")) {
      res.setHeader("Content-Type", "image/tiff");
    }
  },
}));

Pitfalls for image/tiff

Pitfalls that show up for image/tiff, and not for a neighboring type with a similar extension: A multi-page TIFF is one file and one media type. Clients that read only the first directory will look successful and drop the rest of the document. Say so in the API if page two matters. Another trap is JPEG-in-TIFF served as image/jpeg. The outer file is still TIFF until you extract the strip. A third is a ZIP-compressed TIFF, which is common in geospatial files and rejected by decoders that only handle uncompressed strips. Read the compression tag before you promise a preview.

• GeoTIFF is TIFF plus geo keys. The media type is still image/tiff unless you have a more specific contract. The geo keys are tags, not a new header.
• .tif and .tiff should share one types-file line: image/tiff tif tiff.
• The endianness mark is part of the file. Swapping it without swapping the integers corrupts every offset.
• image/x-tiff is unofficial. Send image/tiff.