← Back to release summary

Spec-compliant XML MIME type detection

Category
Network / Connectivity
Type
Chromium catches up
Status
Proposed (Chrome Proposed)
Intent stage
None

WPT details: The implementation adds MIME minimization cases to: mimesniff/mime-types/resources/mime-types-minimized.json These cases are exercised by: resource-timing/content-type-minimization.html Coverage includes text/example+xml, image/example+xml, font/example+xml, uppercase MIME types, and MIME parameters. Parameterized C++ unit tests cover both feature states, existing XML MIME types, additional +xml types, and invalid MIME inputs. Implementation and tests: https://chromium-review.googlesource.com/c/chromium/src/+/8301932 The WPT additions were merged upstream on September 30, 2026: https://github.com/web-platform-tests/wpt/pull/62420 Historical PR-level Firefox and Safari results for the added cases: https://wpt.fyi/results/resource-timing/content-type-minimization.html?run\_id=6323630396145664\&run\_id=5125540410556416 Additional local comparisons were run on October 9, 2026, on macOS 26.5.1 using Safari 26.5, Firefox 157.0.1, and Google Chrome 154.0.8037.58 without changing experimental flags. A local HTTP server served controlled MIME types and response bodies to compare object embedding, direct navigation, XHR document parsing, and XHR text decoding. The same checks were repeated using Chromium 157.0.8092.0 with SpecCompliantXmlMimeTypes disabled and enabled in separate profiles. No differences were observed in those four areas. Resource Timing contentType changed to application/xml for text/example+xml, image/example+xml, and font/example+xml. These local comparisons were separate from the WPT runs and did not test Actor.

Summary

To fully align with Web standards, Chrome is updating how it detects [XML MIME](https://www.rfc-editor.org/info/rfc7303/) types. Chrome will now recognize valid MIME types whose subtype ends in `+xml` as XML across Chrome and Android WebView, including non-application types such as `text/example+xml` and `image/example+xml`. For these responses, `PerformanceResourceTiming.contentType` returns application/xml. The value for image/svg+xml remains unchanged. Enterprise web applications that rely on previous `contentType` values may observe behavior changes. Chrome Actor also uses this shared XML classification for dangerous MIME type navigation checks, so it may block navigations to additional non-application +xml responses. Admins should check whether their applications depend on these MIME types or the previous `contentType` values.

Motivation

Chromium’s blink::IsXMLMimeType helper previously applied generic +xml suffix matching only to application/\* MIME types. The WHATWG MIME Sniffing Standard defines XML MIME types to include valid MIME types whose subtype ends in +xml, regardless of their top-level type. The standard’s MIME minimization algorithm preserves image/svg+xml and returns application/xml for other XML MIME types. Fetch uses this algorithm to populate the response information exposed by PerformanceResourceTiming.contentType. This change brings Chromium’s Resource Timing values for additional non-application +xml types into line with those requirements. XML MIME type definition: https://mimesniff.spec.whatwg.org/\#xml-mime-type MIME minimization: https://mimesniff.spec.whatwg.org/\#minimize-a-supported-mime-type Fetch integration: https://fetch.spec.whatwg.org/\#fetch-response-handover Resource Timing: https://w3c.github.io/resource-timing/\#dom-performanceresourcetiming-contenttype The separate MIMETypeRegistry::IsXMLMIMEType implementation used by XHR and renderer document-processing paths is unchanged. Any future unification of these helpers would require a separate assessment. Implementation, merged behind an experimental feature: https://chromium-review.googlesource.com/c/chromium/src/+/8301932

Standards & signals

Ecosystem

View on chromestatus.com