What is the MIME type for Markdown?

Question

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.

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

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

• http://www.iana.org/go/draft-ietf-appsawg-text-markdown

• https://www.iana.org/assignments/media-types/media-types.xhtml

  Search for markdown.

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.