Two sections in this response:

1. either the citations are very broken, or the motivation for this change is mistaken
2. why this change seems to contradict IETF standards

Quote Not Found in Citation

The justification for this change in behavior cites the WHATWG spec:

Interoperability and Compatibility
This change aligns XML MIME type classification with the existing WHATWG MIME Sniffing Standard.

It links to the capacious definition of an "XML mime type" in the specification linked at top:

On Monday, October 5, 2026 at 11:25:07 PM UTC-4 Chromestatus wrote:
Contact emails
choiw...@gmail.com

Specification
https://mimesniff.spec.whatwg.org/#xml-mime-type

This specification is correctly interpreted to cover text/*+xml as well as application/xml. That part already appears to be unilaterally implemented across all browsers.

What chrome is proposing here is to transform the MIME type into application/xml. I have been unable to find any justification or precedent for actively overwriting information in this way—except for a section in the linked rfc 2046, which is incorrectly titled [RFC7303] in the cited spec section.

The WHATWG spec does not specify normalization into application/xml, which is clearly described as a subtype of the XML MIME types. From the RFC numbering mistake, I assume there must be a distinct specification that chrome is referencing to motivate this facially counterintuitive behavioral change, which in its current form is both forwards and backwards compatible, by coercing data into a separate valid identifier. I'm not a WHATWG wiz yet, so I assume chrome has some very strong precedent for modifying the observed contentType in this way—I would really appreciate a link so I can learn where this change comes from. Because contentType coercion is otherwise a complete fabrication outside the spec, according to the information given herein.

I assume chrome would not take this step without a strong security justification—can you please provide a description of what motivated chrome to propose this change at this time? I understand security concerns are highly sensitive—a very high-level "yes" or "no" would be helpful here.

IETF Precedent

While it remains unclear whether RFC 2046 is the correct reference at all, it does offer some very specific feedback about interpreting xml types. I foresee direct application security concerns arising from the proposed contentType coercion, as well as multiple contradictions with the spirit of RFC 2046.

Precedent In Favor

I begin with the point in favor of chrome's approach:

It may be the case that some user agents, if they can recognize more than one of the formats, will prefer to offer the user the choice of which format to view. This makes sense, for example, if a message includes both a nicely-formatted image version and an easily-edited text version. What is most critical, however, is that the user not automatically be shown multiple versions of the same data. Either the user should be shown the last recognized version or should be given the choice.

In this proposal's favor, this makes clear that the user agent can and should apply judgement regarding the form to present. I do not contest that at all—as above, if this resolves a security concern, I would defer to the cybersecurity experts' judgement.

However, the capacity for interpreting formats in this 1997 RFC describes several assumptions and limitations on that capacity, which I believe contradict the motivation for this change to chrome behavior.

First off, it should be evident that the RFC strongly prefers and in fact assumes the user agent will provide the most applicable form for the context of the request (and, by implication, supports delegating all the way to the user themself to select the desired format). Secondly, and much more crucially, in no way does this allow actively overwriting the format as per this proposal—the framework selects from the given types.

Application is Abstract Interpretation

Particularly puzzling are the examples given of overwriting /text and /image to application/xml. Elsewhere in RFC 2046, we find:

4.5. Application Media Type
The "application" media type is to be used for discrete data which do not fit in any of the other categories, and particularly for data to be processed by some type of application program. This is information which must be processed by an application before it is viewable or usable by a user.

text and images would seem to be the very definition of data the browser would be expected to interpret. If chrome does not support data in these formats, I would assume it could request an external handler program (e.g. the way torrent files pop up a dialog for a handler program from the OS). Here's where I suspect I'm mistaken—rewriting these more-specific content types would seem to make it much more difficult to achieve the context-specific dispatch methodology described above. An application/xml handler is very unlikely to be able to retroactively parse the MIME the same way chrome has. If the content is declared as /text or /image, I want to choose a program for text or images!

That's why I specifically called out the practice of rewriting to a separate valid and existing content-type: this erases information that must be parsed again from scratch, fully obviating the expectations of MIME parsing. If instead the content-type was rewritten to retain the declared type, while also describing chrome's judgement of it as XML, that would be non-breaking, while still maintaining the purpose of this proposal.

However, even that compromise seems hollow, because the content-type already declares itself as xml! From a facial reading of the cited spec, it's already in conformance! Hence why I suspect there's just a spec link that didn't propagate correctly to justify this radical breaking change.

Potential Security Hazards

My main concern is with polyglot inputs—not the kind that actively declare multiple formats by type, but inputs which parse correctly in two evaluation contexts. The erasure of information here seems to be exactly the type of concern demonstrated by the textbook example of RCE vectors (postscript/pdf):

(8) Finally, bugs may exist in some PostScript interpreters which could possibly be exploited to gain unauthorized access to a recipient's system. Apart from noting this possibility, there is no specific action to take to prevent this, apart from the timely correction of such bugs if any are found.

As a user, I have absolutely no clue what my browser or OS would invoke for "application/xml", since XML is a container format, and "application" (as we saw earlier) is expressly the most abstract and least informative classifier. I'm concerned that an OS (or perhaps a browser extension?) might assign a default interpreter for application/xml that, e.g., modifies the windows registry, or perhaps even invokes a container. This wouldn't require malicious intent, but merely result from being the only app that registers application/xml as a possible input. This is one of the failure modes of hastily-written autoconf configure scripts, for example.

That was speculation. Here's the practical result I'm expecting:

• as a user, an image appears as a blob. If I select an image viewer for application/xml, it seems to work—but then my actual xml blobs will be misinterpreted as images, unless I'm very savvy and think to check my default interpreters.
• as a user, I open a blob with my xml viewer (maybe it's that container program I mentioned earlier), which works great! But then I get confusing errors opening images!
• coercing /text to application/xml directly reinterprets data as executable code. This seems facially unsafe, in ways the chrome team has taught me to recognize over their many years of leadership in web security.

Conclusion

This change seems to be an overeager interpretation of the spec, but I understand such a drastic breaking change is likely to be justified by precedent. I apologize profusely if I have missed this in my haste to contribute.

If this was indeed motivated from external factors beyond spec compliance, I believe the nature of this proposal induces a singular degree of risk in its current form, and I would challenge the author to describe a correspondingly drastic motivation which outweighs the risk I've inferred–or to explain my misunderstandings. I understand your time is valuable, so a link is fine.

I am also unnerved by the complete lack of acknowledgement of this spec interpretation by any other browser. If RFC 2046 is in play, this interpretation logic would have been unchanged since 1997 (of the later updates to RFC 2046, I could find none which had any bearing upon this proposal). So there's either a wrong citation link, or every browser has been wrong since 1997. And that seems like a very weak claim to suddenly identify a new behavior, especially when the new behavior is nowhere in the spec (that I could find).

Thanks for your time. Hope your week goes well!