What is the correct MIME type for a font file?

Question

I have not been able to find a canonical source that indicates the correct MIME type for any and/or each type of file format. All the sources that I have found appear to contradict each other and/or the IANA MIME type RFCs and their associated list.

While I am particularly interested in .otf (OpenType) and .ttf (TrueType) file types, an ideal answer would provide a canonical resource for determining the MIME types for a broad spectrum of font file formats, such as those listed on the Font file section of the Wikipedia page: List of file formats. However, given that I can't find such a resource, it seems entirely possible that no such canonical reference exists.

I would like to further clarify that I am not looking for the working MIME type, but for the canonical MIME type. The selected answer to Proper MIME type for fonts states that font/opentype can be used for .otf file. However, as the highest voted answer (by @djsadinoff) explains, font is not a valid IANA content type and this cannot be the correct MIME type.

Answer 1

The lack of a specific media type for font files resulted in the confusing, ever-changing and contradictory mess that smartcaveman describes above. Back in 2012, this question couldn’t really be answered because other than the IANA list, no such canonical reference did exist. Thankfully, this situation has since been rectified …

In February this year (2017), the W3C published the Standards Track RFC 8081: The "font" Top-Level Media Type which greatly simplifies the appropriate media types for font files:

This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations.

It’s quite a readable document and it describes the historical context (lack of “a registration of formats for font”) which gave rise to the confusing mix of media types and sub-types. With the (relatively) recent rise in popularity of downloadable web fonts, the W3C recognised the need for an “intuitive top-level font type”. What they came up with is: font.

Accordingly, the IANA have since updated their official list of Media types with the font media type and all its sub-types that they currently recognise:

collection  font/collection
otf     font/otf
sfnt    font/sfnt
ttf     font/ttf
woff    font/woff
woff2   font/woff2

Answer 2

For your question you may not know the fact about the font type. Use this link Font MIME Types.

roc reports on the Web Fonts battle of which the short version is whether the non-IE browsers should support a DRM format for fonts. (And maybe also whether they can support TrueType and OpenType out of the box.) I don’t really think we should support a DRM format for fonts. It seems like it would set a bad precedent on the Web, might make vendors liable if they don’t enforce things right, and complicates matters for authors.

The W3C has created a draft charter for an EOT Working Group; EOT (Embedded OpenType) being the DRM format Microsoft is advocating. I have no idea how EOT is leading the Web to its full potential, but we’ll see what comes of it.

Aside from the format issue it might be worth considering to introduce a MIME type for fonts. (If this is too late for implementations at this point it might be too late.) The upside is that arbitrary files (say, a text/html file) will not be interpreted as fonts. The downside is that it makes things slightly harder for authors as they have to make sure they label it correctly. (On the Web images (except SVG) and JavaScript are not checked as to whether the resource has the correct MIME type. For images the browser sniffs the image signature and something loaded from a script element is simply executed (not so good, indeed).)

Given that support @font-face will be shipping soonish in Opera, Safari, and Firefox this would need to be decided soon. Probably before the relevant MIME type is standardized through the IETF. Another complication is that OpenType and TrueType can carry either otf and ttf as extension and the operating system deals with it fine. Having a single MIME type for both could probably work though, just like XHTML and SVG can both use text/xml.

Answer 3

Your answer is in the specs.

4.5.1. Octet-Stream Subtype

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data.

Also on page 4 of the same document

(5)   application -- some other kind of data, typically
      either uninterpreted binary data or information to be
      processed by an application.  The subtype "octet-
      stream" is to be used in the case of uninterpreted
      binary data, in which case the simplest recommended
      action

I still wasn't sure if this file was binary data, so I checked the mime-type using the linux file() command.

    $ file --mime-type 
    Days-webfont.ttf: application/octet-stream

There you go it's an octet-stream pretty clear cut!

I still had some suspicions though so I wanted some more resources. How is a browser going to interpret this? Here is what Mozilla has to say...

Note: Because there are no defined MIME types for TrueType, OpenType, and Web Open File Format (WOFF) fonts, the MIME type of the file specified is not considered.

Interesting Mozilla says there is no defined MIME types for .ttf .otf or .woff.

Mozilla also has some resources to help you

determine the correct MIME type of your content

How to determine the correct MIME type for your content

There are several steps which you can take to determine the correct MIME type value to be used for your content.

If your content was created using a vendor's software application, read the vendor's >documentation to see what MIME types should be reported for different media types.

Look in the IANA | MIME Media Types registry which contains all registered MIME types.

If the media type is displayed using a plug-in in Netscape Gecko, install the plug-in and >then look in the Help->About Plug-ins Menu to see what MIME types are associated with the >media type.

Search for the file extension in FILExt or File extensions reference to see what MIME >types are associated with that extension.

I don't recommend you go FILExt page or File extensions reference they don't do anything that file() can't do in bash.

Searching through the docs I found various subtypes of aplication that almost fit the bill; vnd.ms-fontobject, but that's only for .eot files, font-tdpfr, but that's only for .pfr files.

So it appears the specs don't specify

I'm convinced. So I guess your canonical resource would be comparing the output of file() to what is in the specs.

Answer 4

As one of the comments states:

A better mime type would be "application/x-font-opentype" or "application/octet-stream". The first is basically "unregistered mimetype with this name", the second just "binary data"

Either of these would be technically correct because the first is an accepted MIME type format for unofficial types, and the second is a generic MIME type for binary data without a more specific official MIME type. I verified this claim against RFC2046 and it seems to hold up. Until one becomes official, the most correct way is to use an accepted format for unofficial types, or to use a generic type.

Answer 5

At this point in time, OpenType and TrueType do not seem to have any specifically “correct” MIME types.

The Web Open Font Format—which can be used as a wrapper for both—however, has application/font-woff (registered by the W3C). The Embedded OpenType format—a compact version of OpenType—uses application/vnd.ms-fontobject (registered by Microsoft).

If you want to go back into time, you can use application/font-tdpfr for a TrueDoc Portable Font Resource. This was natively supported by Netscape Navigator 4. ☺