免费XML转JSON转换器

什么是XML？

XML（可扩展标记语言）是一种用于存储和传输数据的格式。它使用自定义标签来描述数据结构，使其人类可读且广泛受支持。与JSON不同，XML可以在元素上包含属性。

为什么要将XML转换为JSON？

• 文件体积更小 · JSON比XML更紧凑。
• Web API · 大多数现代Web服务使用JSON而不是XML。
• 更容易解析 · JSON直接映射到JavaScript对象。
• 遗留系统集成 · 将旧XML数据转换为现代JSON格式。

常见问题

XML属性是如何处理的？

XML属性被转换为带有@前缀的JSON属性（例如@id、@href）。这在JSON结构中保留了属性信息。

命名空间怎么处理？

命名空间会在输出中保留。前缀会包含在元素名称中（例如“ns:element”）。

可以将JSON反转为XML吗？

此工具将XML转换为JSON。反向转换请使用我们的JSON转XML转换器。

Two formats, three decades apart

XML 1.0 became a W3C Recommendation on 10 February 1998. The original editors were Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) and C. M. Sperberg-McQueen (University of Illinois at Chicago); the Working Group was chaired by Jon Bosak of Sun Microsystems. XML's lineage runs back to SGML (ISO 8879:1986), the document-markup standard that itself grew from IBM's GML in the 1970s. SGML was powerful but daunting; XML's design brief was "design a 'lite' version of SGML", trimming optional features to a profile that could be implemented in a few thousand lines of code while preserving Unicode, namespaces and attribute-rich documents.

JSON (JavaScript Object Notation) was discovered, not designed. Douglas Crockford and Chip Morningstar sent the first JSON message in April 2001 at State Software, deriving the format from JavaScript's object-literal syntax. Crockford registered json.org in 2002 and put up a one-page spec. The format was first formalised as RFC 4627 in July 2006, re-issued as RFC 7159 in 2014, and stabilised as RFC 8259 / STD 90 in December 2017, the same year ECMA-International published ECMA-404. JSON's design intent (per Crockford's retrospective): minimal, language-independent, easy to generate and parse, no version number ("there is no version number"), and deliberately no comments ("I removed comments because I saw people were using them to hold parsing directives").

JSON took over web APIs in the late 2000s as REST replaced SOAP and as XMLHttpRequest gave way to JSON-over-fetch. By 2015 JSON was the default response format of nearly every public API; XML survived in long-tail enterprise SOA, document formats (Office Open XML, OpenDocument), and standards-bound niches.

Where XML and JSON differ

	XML	JSON
Attributes	First-class (<item id="5"/>)	No attributes, everything is a key/value pair
Namespaces	Native (xmlns:prefix="uri")	Flat names; prefix collisions are the app's problem
Comments	<!-- … -->	None per spec
Mixed content	Native (<p>text <b>and</b> markup</p>)	Awkward, needs arrays or stringification
Schema	DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron	JSON Schema (community spec, draft 2020-12)
Order	Element order is significant per spec	Object key order not guaranteed (most parsers preserve insertion order in practice); arrays are ordered
Numbers	Strings until typed by schema	IEEE 754 double; no integer/float distinction at spec level
Verbosity	High (every value wrapped in tags	Low) punctuation only

Why XML→JSON is fundamentally lossy

There is no W3C-blessed canonical mapping from XML to JSON. Every converter has to invent answers to questions XML allows you to express but JSON has no native vocabulary for. The recurring decisions:

• Attributes vs child elements: XML lets you express the same data both ways. JSON has only one notion (keys on an object), so the converter must invent a marker. The common conventions: BadgerFish uses @ for attributes and $ for text; Parker drops attributes entirely (lossy but simple); JsonML represents elements as arrays with type tags (preserves order and structure); GData / Newtonsoft / xml2js use an @attributes sub-object plus a #text key when needed. This converter follows the GData-style convention: attributes under @attributes, mixed-content text under #text, repeated children become arrays.
• Repeated child elements: if the converter blindly creates one key per child, the second child overwrites the first. Standard fix: detect repetition and emit an array. But this means the JSON shape depends on data, one <book> produces a string, two produce an array of strings. Some consumers want the array form even for one item; some converters expose an "always-array" toggle for specific element names.
• Mixed content: <p>Hello <b>world</b>!</p> intermixes text and elements with significant order. JSON cannot natively express that interleaving without an array of mixed types or a sentinel #text key. Many converters drop the prose between elements; the more conservative ones split it into multiple text-node entries.
• Namespaces: <soap:Envelope xmlns:soap="…"> has both a prefix and a binding URI. Most converters preserve the prefix as part of the JSON key (soap:Envelope) and drop the binding, which is fine as long as the consumer doesn't need to resolve the namespace.
• Comments and processing instructions: usually dropped silently, since JSON has no comment syntax.
• CDATA sections: flattened to plain strings; the <![CDATA[…]]> wrapper is lost.
• Whitespace: XML has xml:space="preserve" for significant whitespace; JSON has no equivalent. Most converters trim whitespace-only text nodes between elements.

When you'd reach for this

• Consuming legacy SOAP services from a modern JS frontend. SOAP responses are XML; converting once at the boundary lets the rest of the app work in JSON.
• RSS / Atom feed processing: both are XML formats; modern news readers and aggregators usually want JSON.
• XML sitemaps (sitemap.xml), converting to JSON makes them easier to inspect and process programmatically.
• OpenStreetMap OSM data: published as XML, frequently needed as JSON for client-side mapping.
• Google Earth KML / GPX files: geographic data formats that come in XML.
• Office Open XML internals: .docx, .xlsx and .pptx are zipped XML files; if you've extracted one and want to inspect its structure as JSON, this is the conversion step.
• SVG manipulation: SVG is XML. Converting to JSON makes it easier to walk and mutate the tree in JavaScript before re-serialising.
• Maven POM, Ant build files, Spring config, Android resources, Apple plists, XBRL financial data, HL7 medical records, MusicXML, NMX legal documents: long-tail XML formats that often need JSON for downstream tooling.

Modern alternatives

• Native JSON APIs. If the upstream service offers a JSON variant, take it. SOAP services typically don't but most modern equivalents do.
• GraphQL. A query language that lets the client request exactly the JSON shape it needs from a typed schema.
• Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Binary serialisation formats with schemas and much smaller wire sizes than either XML or JSON. Common inside microservice meshes; rarely used at the browser boundary because they need explicit decoding libraries.
• Stay in XML. If the data is genuinely document-oriented (mixed content, deep typed structure, schema validation that matters), XML is the better fit. JSON's strength is API-shaped data; document fidelity isn't its specialty.

More questions

Why does the same XML produce a different JSON shape on different tools?

Because there is no canonical XML→JSON mapping. Each converter picks a convention (BadgerFish, Parker, JsonML, GData-style) and the resulting JSON shapes differ in how attributes are marked, how mixed content is preserved, and how repeated children are arrayed. Round-tripping XML through different converters produces different JSON; round-tripping JSON back to XML through different converters can change attribute placement and even element ordering. For interoperability, document the convention you're using and stick to it.

What about CDATA, comments and processing instructions?

CDATA sections (<![CDATA[…]]>) are flattened to plain string content, the wrapper is gone, but the text inside is preserved verbatim. XML comments (<!-- … -->) and processing instructions (<?xml-stylesheet …?>) are dropped, since JSON has no syntax for either. If you need round-trip fidelity that preserves comments, an XML-only round trip is the right approach.

Will my XML schema (XSD) survive the conversion?

No. XSD describes XML structure and types; JSON Schema is the analogous (separate) standard for JSON. Some advanced tooling can translate XSD to JSON Schema, but it's a lossy operation, XSD has features (mixed content, substitution groups, derived types) that have no clean JSON Schema equivalent. For document validation that matters, run XSD against the original XML, not against the JSON conversion.

Why did JSON win for web APIs?

A few reasons. JSON maps directly to JavaScript objects, so browser-side parsing is one JSON.parse() call away. The format is much smaller, no closing tags, no namespace declarations, no schema baggage. REST replaced SOAP for most public APIs in the late 2000s, and JSON was the natural payload for REST. XML's strengths (strict schemas, namespaces, mixed content) matter for documents and legacy enterprise systems but rarely for "give me the user object." The web optimised for the simpler case.

Does anything get sent to a server?

No. The XML is parsed by the browser's native DOMParser, then walked recursively in JavaScript to build the JSON output. Pasted XML never leaves the page. The tool works offline once it's loaded, which matters when the source XML contains internal API endpoints, customer data, or proprietary schemas you'd prefer not to upload anywhere.

相关工具