Loading…
Convert XML into JSON with a consistent attribute and repeated-element mapping — parsed safely in your browser.
Your JSON will appear here after you convert.
XML carries information JSON has no direct slot for — attributes, namespaces, text mixed with elements — so converting to JSON needs a documented convention. This tool uses a consistent, predictable mapping.
<user id="123">
<name>John</name>
<roles>
<role>admin</role>
<role>editor</role>
</roles>
</user>{
"user": {
"@id": "123",
"name": "John",
"roles": {
"role": ["admin", "editor"]
}
}
}@name keys, e.g. @id.#text key.ns:tag) and xmlns attributes are preserved literally.Mixed content (text interleaved with child elements, like <p>Hello <b>world</b>!</p>) keeps the combined text but not its exact position — a documented limitation. For security, DOCTYPE is rejected so external-entity (XXE) and entity-expansion attacks are impossible, and everything is treated as inert data. To convert back, use JSON to XML; validate the result with the JSON Validator.
Attributes become keys prefixed with @. For example <user id="123"/> becomes {"user":{"@id":"123"}}.
Repeated child elements with the same name become a JSON array, so nothing is overwritten. <users><user>A</user><user>B</user></users> becomes {"users":{"user":["A","B"]}}.
Element text is placed in a #text field when the element also has attributes or children. Mixed content (text interleaved with child elements) keeps the concatenated text but not its exact position — a documented limitation.
Yes. DOCTYPE declarations are rejected, so there are no custom or external entities. XXE, external-resource loading, and entity-expansion (billion laughs) attacks are structurally impossible, and the converter never makes network or file requests.
No. XML text has no types, so all values are kept as strings (e.g. <age>30</age> becomes "30"). Use the JSON tools afterward if you need typed data.