Mapping JSON and XML without losing attributes, order or meaning

The two formats model different things

JSON has objects, arrays and primitive values. XML has elements, attributes, text nodes, namespaces and an ordered sequence of children. A converter must choose conventions because there is no universal one-to-one mapping between those models.

A simple object with scalar properties maps cleanly. Difficult cases appear when an element contains both text and child elements, when repeated children imply an array, or when an attribute and child share the same local name.

Define attribute and array conventions

XXF prefixes XML attributes with an at sign in JSON so they remain distinct from child elements. When converting in the other direction, arrays become repeated elements under the array property name. These choices are readable, but the receiving system may use a different convention.

• Document the attribute prefix
• Decide how empty elements map to null or empty strings
• Keep array order when sequence matters
• Choose an explicit root element

Treat namespaces as data

Namespaces prevent collisions between vocabularies and often carry contract meaning. Removing prefixes because they look decorative can merge unrelated names or break schema validation. Preserve the namespace declarations required by the target integration.

If the destination validates against an XSD or a published feed specification, test the converted document with that validator rather than relying on well-formedness alone.

Test a representative round trip

Build a small sample containing attributes, repeated children, empty values, Unicode text and the deepest nesting used in production. Convert it in both directions and compare the parsed meaning, not only the formatting.

Check an attribute and repeated elements

Run this compact document through XML to JSON. XXF preserves the id attribute under @id and combines repeated product elements into an array. The parser also interprets numeric element text as numbers. If the receiving system needs a lexical value such as 19.90 rather than a numeric value, that distinction needs an explicit mapping policy.

Converting the JSON back does not automatically recreate the original document. The JSON to XML builder uses its own attribute convention, so an @id key from the parser is not a guaranteed inverse mapping. Review the actual output rather than assuming that similarly named conversion buttons are lossless inverses.

<catalog><product id="p1"><name>Keyboard</name></product><product id="p2"><name>Mouse</name></product></catalog>

{
  "catalog": {
    "product": [
      {
        "name": "Keyboard",
        "@id": "p1"
      },
      {
        "name": "Mouse",
        "@id": "p2"
      }
    ]
  }
}

Do not infer a schema from one occurrence

A single product element can become an object, while repeated products become an array. Normalize that boundary according to the API contract before reading product[0]. Namespaces, mixed text and child content, comments and ordering have additional XML semantics that a plain JSON object may not represent.

For an integration, prepare fixtures with zero, one and several records and compare the schema-required result in each case. Use an XML validator or the receiving service for well-formedness and schema checks: this conversion page does not claim to validate an XSD or preserve every XML document feature.

• Define an explicit attribute naming convention
• Normalize singular and repeated elements
• Check lexical numbers and whitespace requirements
• Validate the destination contract separately