RFC 6838 is clear about the `text` top-level type [1]: > The "text" top-level type is intended for sending material that is principally textual in form. [...]

RFC 6838 is clear about the `text` top-level type [1]: > The "text" top-level type is intended for sending material that is principally textual in form. [...] Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In comparison, if `text/*` should be used for any format that encodes something in a text format as Crockford wanted, then you can put every file format into `text/*` with base64 encoding in principle. Limiting `text/*` to the data that is textual in nature avoids this issue by setting a reasonable expectation [2]. It is even possible to register `text/vnd.foobar+json` if you want, because a structured syntax suffix `+json` doesn't affect the top-level type. But JSON in general doesn't guarantee any textual data even after processing. [1] https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 [2] Therefore `text/rtf` is possible when it doesn't embed any additional object, otherwise `application/rtf` should be used. It is debatable whether a source code is a text or not however, especially when it can be executed in place. The transition from `application/javascript` to `text/javascript` [3] is one example. [3] https://datatracker.ietf.org/doc/html/rfc9239 https://datatracker.ietf.org/doc/html/rfc9239