application/xml XML Flagship

What it's for

application/xml identifies data formatted as XML (Extensible Markup Language) — a verbose, tag-based structured data format that predates JSON as the standard for machine-readable data interchange. While JSON has taken over most new API design, XML remains heavily entrenched in specific ecosystems: SOAP web services, many enterprise and government systems, RSS/Atom feeds (which use their own more specific types but are XML underneath), Microsoft Office file internals, and configuration formats across countless older or enterprise-grade systems.

You'll encounter application/xml far more often maintaining or integrating with existing systems than building something new from scratch — but that "existing systems" category is still enormous, particularly in enterprise, government, and finance.

Format & syntax

Content-Type: application/xml
Content-Type: application/xml; charset=utf-8

XML documents are tag-based, requiring a well-formed structure with matching opening/closing tags, a single root element, and (unlike HTML) strict adherence to rules — every tag must close, attribute values must be quoted, and special characters need escaping (&, <, >, etc.). An optional XML declaration typically appears at the top: <?xml version="1.0" encoding="UTF-8"?>.

There's also text/xml, an older, still-valid alternative type — the practical difference is subtle (character encoding handling defaults differ slightly), but application/xml is the more modern, generally recommended choice per RFC 7303.

How it's used in practice

• SOAP web services — enterprise integration APIs, especially older or larger organizations' systems, frequently still use SOAP, which is XML-based end to end, including the envelope, headers, and body structure.
• RSS/Atom feeds — technically served with their own more specific MIME types (application/rss+xml, application/atom+xml), but both are XML dialects underneath.
• Sitemaps — sitemap.xml files served to search engines are XML, typically served with application/xml (though text/xml also works for this purpose).
• Configuration and data files in enterprise systems — many enterprise Java applications, .NET systems, and legacy platforms use XML extensively for configuration, data exchange, and internal document formats.
• SVG — technically an XML-based format (image/svg+xml), demonstrating that XML's tag structure extends well beyond generic "data interchange" into markup and graphics formats too.

Common mistakes & gotchas

• Confusing application/xml and text/xml — both are valid and widely supported, but they differ subtly in default charset handling per spec. application/xml is the more modern recommendation (RFC 7303); if you're building something new, prefer it, but don't be surprised to see text/xml in older or established systems.
• Malformed XML failing silently or with unclear errors — unlike HTML parsers (which are famously lenient), XML parsers are strict — a single unclosed tag or unescaped ampersand can cause an entire document to fail to parse, sometimes with error messages that don't clearly point to the actual problem location.
• Forgetting to escape special characters — &, <, and > have special meaning in XML and must be escaped (&, <, >) when they appear as literal data rather than markup; forgetting this is one of the most common XML generation bugs.
• Assuming XML namespaces are simple — XML namespace handling (the xmlns attribute and prefix system) trips up developers new to XML far more than JSON's flat structure ever does; SOAP APIs in particular can involve deeply nested namespace declarations that are easy to get wrong when hand-constructing requests.

Comparison & FAQ

Should I use application/xml or text/xml for a new project?

application/xml is the more modern, generally recommended choice per RFC 7303, though both remain valid and widely supported. If you're integrating with an existing system that expects one specifically, match what it expects.

Why does my XML fail to parse when it looks correct?

Check for unescaped special characters (particularly &), unclosed tags, or multiple root elements — XML parsers are strict and will reject documents that HTML's lenient parsing would have silently accepted with a similar structural issue.

Is XML being replaced entirely by JSON?

For new API design, largely yes — JSON is the modern default. But XML remains deeply entrenched in SOAP services, many enterprise/government systems, RSS/Atom feeds, and document formats like SVG and Office file internals, so it's far from obsolete in practice.

Do I need to declare an XML namespace?

Only if your document combines vocabularies from multiple XML schemas (common in SOAP and complex enterprise formats) — simple, single-purpose XML documents often don't need explicit namespace declarations at all.