588

This is more of a general question about the difference between text/xml and application/xml. I am fairly new to writing webservices (REST - Jersey). I have been producing application/xml since it is what shows up in most tutorials / code examples that I have been using to learn, but I recently found out about text/xml and was wondering what is different about it and when would you use it over application/xml?

Mike
  • 8,137
  • 6
  • 28
  • 46
  • 6
    As noted in DaveV's answer, and in the header at https://tools.ietf.org/html/rfc3023, RFC 3023 (cited by Oded's answer, currently accepted) is obsolete. The newer RFC 7303 actually gives a significantly different answer to this question than RFC 3023 used to. I think it would therefore be helpful to future readers if you accepted DaveV's answer, so that the most up-to-date information is kept at the top of the answer list. – Mark Amery Jan 26 '19 at 17:19
  • Based on Dave V below and Marián Černý it appears that application/xml is preferred now if you were doing something new. – Sql Surfer Mar 27 '19 at 15:29
  • `text/` is meant for humans. `application/` is meant for computers – Ian Boyd Sep 24 '19 at 15:05

5 Answers5

485

From the RFC (3023), under section 3, XML Media Types:

If an XML document -- that is, the unprocessed, source XML document -- is readable by casual users, text/xml is preferable to application/xml. MIME user agents (and web user agents) that do not have explicit support for text/xml will treat it as text/plain, for example, by displaying the XML MIME entity as plain text. Application/xml is preferable when the XML MIME entity is unreadable by casual users.

(emphasis mine)

Community
  • 1
  • 1
Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 1
    So reading the part that you quoted, reckon what a non-human-readable XML looks like, since XML is pretty much text. I suppose if you embedded binary or base64 encoded data ... – jcolebrand Jan 28 '11 at 19:51
  • 7
    @drachenstern - I think non descriptive elements and attributes more likely (``, for example as unreadable by _casual_ users). – Oded Jan 28 '11 at 19:53
  • So if I am creating the xml myself and producing it as a response, is it up to ME to use non-descriptive elements and attributes then if I am using application/xml? – Mike Jan 28 '11 at 20:07
  • @Mike - this is what the RFC says. However, in my experience, it doesn't really matter which one you use. – Oded Jan 28 '11 at 20:09
  • 1
    @Mike I think a less subjective distinction is along the lines of record-based xml content and document-based xml content. – biziclop Jan 28 '11 at 20:23
  • @biziclop I'm sorry but I don't quite understand what you mean, could you expand on that? – Mike Jan 28 '11 at 20:30
  • 3
    @Mike Of course. Some XML files are basically a list of records, like this: http://msdn.microsoft.com/en-us/library/ms762271%28v=vs.85%29.aspx This is more likely to be read and processed by an application. Others are basically text with markup, like a HTML page. Using text/xml for them sounds more appropiate. – biziclop Jan 28 '11 at 20:44
  • 7
    Please give an example of unreadable vs readable. We use files that are mostly readable but do have base64 encoded nodes, etc.. – Joe Phillips Feb 21 '13 at 16:11
  • 5
    @JoePhilllips - There you go. base64 is not readable by humans. If the entire document can be read and make sense to a human without tools or looking at a manual (what's that `xgsf` tag mean?), then it is readable. – Oded Feb 21 '13 at 16:21
  • 3
    This answer explains the *intent* behind text/xml vs. application/xml but it doesn't explain *the technical difference* between the two. What actually changes when "application/xml" is used instead of "text/xml"? – CommaToast Nov 13 '14 at 23:12
  • 8
    @CommaToast A web server might return formatted and indented XML if "text/xml" is the Accept, whereas application/xml might return all insignificant whitespace removed. In ASP.NET MVC for example, you can specify different handlers for different mimetypes. – Novaterata Jul 20 '15 at 20:07
  • I'll give you another reason to use text instead of application. I just spent half the day fighting how our code to pull files (Java & C#) from several web servers started failing. Changed from application to text and it worked. No beeping idea why. – David Thielen Jul 10 '20 at 01:23
172

This is an old question, but one that is frequently visited and clear recommendations are now available from RFC 7303 which obsoletes RFC3023. In a nutshell (section 9.2):

The registration information for text/xml is in all respects the same
as that given for application/xml above (Section 9.1), except that
the "Type name" is "text".
Community
  • 1
  • 1
DaveV
  • 1,876
  • 1
  • 11
  • 4
  • 10
    The cited paragraph mentions IANA registration information, which (by checking Section 9.1) deals also with the encoding, so there should not be any more any differences in character set handling between `application/xml` and `text/xml`. In addition, I consider this part of the abstract: "This specification standardizes ... application/xml ... while defining text/xml ... as alias..." to mean that `application/xml` and `text/xml` are equivalent and there is no preference of one about the other. – Marián Černý May 04 '18 at 09:45
  • 3
    @MariánČerný wouldn't the fact that one is "standard" while the other is an "alias" basically mean that `application/xml` is the one to use by default? Seems to me that the only reason to keep `text/xml` at this point is for backwards compatibility given the standardization is happening on `application/xml` instead. – julealgon Oct 31 '21 at 00:30
40

According to this article application/xml is preferred.

EDIT

I did a little follow-up on the article.

The author claims that the encoding declared in XML processing instructions, like:

<?xml version="1.0" encoding="UTF-8"?>

can be ignored when text/xml media type is used.

They support the thesis with the definition of text/* MIME type family specification in RFC 2046, specifically the following fragment:

4.1.2.  Charset Parameter

   A critical parameter that may be specified in the Content-Type field
   for "text/plain" data is the character set.  This is specified with a
   "charset" parameter, as in:

     Content-type: text/plain; charset=iso-8859-1

   Unlike some other parameter values, the values of the charset
   parameter are NOT case sensitive.  The default character set, which
   must be assumed in the absence of a charset parameter, is US-ASCII.

   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.  For other subtypes of "text"
   than "text/plain", the semantics of the "charset" parameter should be
   defined to be identical to those specified here for "text/plain",
   i.e., the body consists entirely of characters in the given charset.
   In particular, definers of future "text" subtypes should pay close
   attention to the implications of multioctet character sets for their
   subtype definitions.

According to them, such difficulties can be avoided when using application/xml MIME type. Whether it's true or not, I wouldn't go as far as to avoid text/xml. IMHO, it's best just to follow the semantics of human-readability(non-readability) and always remember to specify the charset.

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
hardywang
  • 4,864
  • 11
  • 65
  • 101
  • 2
    +1 for the link. In your own words, what is the basic conclusion reached in the article? Maybe "the article states that file encoding is ignored, which means you can't send utf-8 and binary data in a file with a text/xml header" also is this verified? – Shanimal Apr 26 '12 at 14:47
  • I agree with @Shanimal, the answer should include the gist of the article as the link may not last forever. Its disappearance will render the answer pretty much useless. Could anyone confirm the statement about ignoring XML processing instructions concerning encoding? – toniedzwiedz Jul 13 '12 at 08:31
  • 1
    According to the original author, this has been fixed in later revs of the specifications `Update: The situation has changed in the new HTTP/1.1 RFC: The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says.` – TheNorthWes Mar 20 '15 at 17:45
  • If I load an XML file with ajax it is a "document" of type `application/xml` but if I use an input form element it is a "file" of type `text/xml` which does not process properly with my code. How can I convert it to the other format? –  May 18 '16 at 15:29
11

application/xml is seen by svn as binary type whereas text/xml as text file for which a diff can be displayed.

Tim S. Van Haren
  • 8,861
  • 2
  • 30
  • 34
Michał Kawiecki
  • 375
  • 3
  • 7
2

Web browsers display text/plain as plaintext while most browsers will parse application/xml into data tree, with syntax highlighting, or even go further and apply transformation declared using XSLT. Some browsers cut off rendering application/xml as data tree when an error is detected, but will always display text/xml in full regardless of errors in syntax.

KHAYRI R.R. WOULFE
  • 189
  • 2
  • 5