116

Does anyone know if there exists a MIME type for Markdown? I guess it is text/plain, but is there a more specific one?

janw
  • 5,204
  • 5
  • 24
  • 43
ilanco
  • 8,757
  • 4
  • 29
  • 37

5 Answers5

128

tl;dr: text/markdown since March 2016

In March 2016, text/markdown was registered as RFC7763 at IETF.

Previously, it should have been text/x-markdown. The text below describes the situation before March 2016, when RFC7763 was still a draft.


There is no official recommendation on Gruber’s definition, but the topic was discussed quite heavily on the official mailing-list, and reached the choice of text/x-markdown.

This conclusion was challenged later, has been confirmed and can be, IMO, considered consensus.

This is the only logical conclusion in the lack of an official mime type: text/ will provide proper default almost everywhere, x- because we're not using an official type, markdown and not gruber. or whatever because the type is now so common.

There are still unknowns regarding the different “flavors” of Markdown, though. I guess someone should register an official type, which is supposedly easy, but I doubt anyone dares do it beyond John Gruber, as he very recently proved his attachment to Markdown.

There is a draft on the IETF for text/markdown, but the contents do not seem to describe Markdown at all, so I wouldn't use it until it gets more complete.

MattiSG
  • 3,326
  • 1
  • 18
  • 30
125

There is no official standard type, but text/markdown seems to be the most common de facto type. Most browsers and other reasonably sophisticated clients will likely see the text/ part and default to text/plain anyway, so there's not much difference.

One caveat, though: all types under the text/ hiearchy default to ISO-8859-1 for their character type in the relevant RFC standards. Most of the world has since moved on to UTF-8. So unless you're positive you won't be using any funny characters (or live in an old Windows world) you might want to specify it as follows:

text/markdown; charset=UTF-8
Eddie C.
  • 787
  • 9
  • 16
SFEley
  • 7,268
  • 5
  • 25
  • 31
  • 3
    Would have been awesome if mail clients supported this and used the Daringfireball Markdown as the basis for it. Unfortunately, they do not. I'm not even aware if anyone has submitted it to the IETF as a draft RFC. I also researched Enriched Text MIME type, and found that this is no longer supported in many mail clients -- which now favor HTML Mail. Besides, [Enriched Text format](http://en.wikipedia.org/wiki/Enriched_text) never supported hyperlinks. – Volomike Oct 02 '12 at 18:34
  • 38
    By "funny characters" you mean the characters the vast majority of the world uses to communicate on a daily basis. – keegan Oct 24 '12 at 18:46
  • 41
    Yes, exactly. There are a lot of funny characters in the world. I try to be one of them. – SFEley Mar 11 '13 at 22:28
  • 32
    If you're implementing this yourself, you should use `text/markdown`: `x-` prefixes were deprecated by [RFC 6648 (Best Current Practice 178)](http://www.rfc-editor.org/bcp/bcp178.txt) in June 2012. – Stuart P. Bentley Mar 24 '13 at 01:03
  • 1
    Stuart P. Bentley: Excellent. Hooray for progress. >8-> – SFEley May 13 '13 at 17:50
  • The "relevant RFC" seems to be RFC 1521. But at least there the default charset is defined as `us-ascii`, not `iso-8859-1`. See http://tools.ietf.org/html/rfc1521#section-7.1.1 – Daniel Rikowski Sep 13 '13 at 09:34
  • 1
    Daniel: That's out of date. There have been numerous "relevant" RFCs since 1521, and they were in partial contradiction. [RFC 2046](http://tools.ietf.org/html/rfc2046#section-4.1.2) says `The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.` But [RFC 2616](http://tools.ietf.org/html/rfc2616#section-3.7.1) said that for HTTP/1.1 headers: `When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.` That's cleared up with 6648. – SFEley Oct 24 '13 at 19:16
  • Note this answer still doesn't work for file uploads: http://jsfiddle.net/JZ5jz/ `` – tim peterson Apr 30 '14 at 17:00
10

Looks like text/markdown is going to be the standard.

Nicholas Carey
  • 60,260
  • 12
  • 84
  • 126
anatoly techtonik
  • 17,421
  • 8
  • 111
  • 131
6

Found this thread from 2008 : http://www.mail-archive.com/markdown-discuss@six.pairlist.net/msg00973.html

Seems like the mime type text/vnd.daringfireball.markdown should be registered by the author of Markdown, until then the Markdown mime type can be specified as text/x-markdown.

ilanco
  • 8,757
  • 4
  • 29
  • 37
0

According to RFC7763 “The text/markdown type” from 2016, the general MIME type is

text/markdown; charset=UTF-8

where the charset parameter is required but need not be UTF-8.

That RFC also specifies an optional variant parameter, and the Internet Assigned Numbers Authority maintains a registry of Markdown Variants by which the specific variant of Markdown can be specified, e.g.,

text/markdown; charset=UTF-8; variant=Original
text/markdown; charset=UTF-8; variant=GFM
text/markdown; charset=UTF-8; variant=CommonMark

Some variants allow further parameters, as specified in RFC7764 “Guidance on Markdown”, e.g., you could add extensions=-startnum with the pandoc variant to specify a tweak to the dialect, although I do not know how/whether pandoc might actually interpret that.

Why is the character set required?

RFC2046 “MIME Part Two” from 1996 set US-ASCII as the default character set, but also said

The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly restrict its values as well.

Then RFC2616 “HTTP/1.1” from 1999 specified ISO-8859-1 as the default character set for text/* transported over HTTP, and with the web becoming a dominant mode of communication, this became the presumed default encoding for text/* media types.

Without an explicit character set or registered mime-type-specific default, text/* is considered to be US-ASCII, unless said text is transported over HTTP in which case it is considered to be ISO-8859-1.

RFC 6657 “Update to MIME regarding "charset" Parameter Handling in Textual Media Types” attempted to clarify this discrepancy by requiring all new media type registrations to explicitly specify how to determine the character set, preferably by including it in the payload as HTML allows with <meta charset=UTF-8>.

The text/markdown registration specifies the charset parameter as “Required.” Therefore using a content-type of text/markdown is technically invalid, and the character set of such content may legitimately be interpreted as any of undefined, invalid, US-ASCII, ISO-8859-1, or the UTF-8 that in practice it will almost always be.

andrewdotn
  • 27,806
  • 6
  • 80
  • 110