Take the 2-minute tour ×

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.

share|improve this question
add comment

4 Answers

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.

share|improve this answer
add comment

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

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.

share|improve this answer
application/octet-stream is a generic catch-all. The problem is it doesn't indicate anything to a client about the file. It's just a super class of all file types that contain binary data. (e.g. you can mark a pdf as application/octet-stream, but its specific type is application/pdf) –  smartcaveman Oct 3 '12 at 16:05
Right. I understand, but there is no spec application/octet-stream is what we have right now. –  shakabra Oct 4 '12 at 7:52
it's not that I think you're wrong, I'm just hoping there's something neither of us have found. –  smartcaveman Oct 8 '12 at 9:38
@shakabra is right. you should use application/octet-stream as it fits all kinds of binary data. Trying to "invent" your own mime type will yield no benefits. –  Martin Müller Oct 9 '12 at 14:46
add comment

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.

share|improve this answer
add comment

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. ☺

share|improve this answer
add comment

Your Answer


