Utilo

TAR MIME Type – Free, Online, Private

application/x-tar is the type servers use for an uncompressed tar archive. A .tar.gz file is application/gzip, not this type.

What .tar is

tar is a sequence of 512-byte blocks. Each member starts with a header block whose name field is the path, followed by the file bytes padded to a block. There is no central directory. You scan from the start. The traditional magic appears at offset 257 in a ustar header and reads ustar. Very old headers omit it. Two zero blocks end the archive. Servers map .tar to application/x-tar. That value is not in the current IANA media-type list. It is still the type Apache, nginx, and every client that unpacks a .tar download agree on. A compressed tarball is a different type because the bytes on the wire are gzip, bzip2, or xz.

Static servers send application/x-tar for an uncompressed tar archive. The current IANA media-type list does not register application/x-tar. application/gzip is the type once the archive is gzip-compressed. The media type is application/x-tar. Extensions that use it on this page: .tar. 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 application/x-tar

What sends application/x-tar: Send application/x-tar for a .tar file that is not compressed. Send application/gzip for .tar.gz and .tgz. Do not send application/x-tar for a gzip body or the client will try to read ustar out of a 1F 8B stream and fail. Set a filename. Tar has no inherent compression, so Content-Encoding: gzip is a reasonable extra layer if you must compress on the fly, and then the type stays application/x-tar. That is different from a .tar.gz file you already stored, which is application/gzip. Say which one you are doing. The file on disk is still .tar. Once the response exists, a client trusts application/x-tar, not the filename. If you publish a source tarball and a gzip of the same bytes, use two URLs and the two types. A query string that switches compression is how a cache serves the gzip bytes to a client that asked for tar, unless Vary lists that parameter. Two paths are easier.

Content-Type for .tar

Send application/x-tar 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: application/x-tar

nginx, Apache, and Express

These snippets map .tar to application/x-tar. 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 .tar 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
application/x-tar           tar;
ApacheAddType application/x-tar .tar
Expressimport express from "express";

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

Pitfalls for application/x-tar

Pitfalls that show up for application/x-tar, and not for a neighboring type with a similar extension: The mix-up with gzip is the whole operational story and it is covered above because people hit it constantly. The next bug is a tar that contains absolute paths or .. segments. Extract with a path check. The type will not do it. Another bug is a pax or GNU long-name header that a naive reader skips, so the extracted filename is truncated. Another is a sparse file that extracts as a huge run of zeros and fills the disk. Another is a tarball of a single top-level directory versus a tarball of many files at the root. Document which one you ship so a script does not scatter files.

  • application/x-tar is the de facto type and is not an IANA registration. There is no application/tar in the current list either.
  • ustar at offset 257 is the POSIX header magic. Its absence does not prove the file is not tar.
  • A .tar.gz response is application/gzip. Uncompressing it on the server and sending application/x-tar is a different representation.
  • Do not add a charset. Header bytes are binary, and filenames inside may be a locale you did not record.

Frequently asked questions

Is application/x-tar registered at IANA?

No. It is the type static servers and tar clients use. The current IANA list does not include it.

What type is .tar.gz?

application/gzip. application/x-tar is the uncompressed archive.

How do I recognize a tar file?

Look for ustar at offset 257 in a POSIX header, then 512-byte blocks. Old pre-ustar archives may not have that string.

Should I gzip a tar response?

Either store a .tar.gz and send application/gzip, or send application/x-tar with Content-Encoding: gzip. Do not mix those stories.