When you run XML through the site’s XML to JSON converter, one <item> comes out as a JSON object while two come out as an array. That is the XML to JSON single element object, multiple elements array behavior, and it happens because the converter groups repeated sibling elements with the same tag name into an array. A lone element has nothing to group with, so it stays an object.
This article assumes you know basic XML elements and the difference between JSON objects and arrays. The input is a well-formed XML feed, the output is JSON, and the practical outcome is deciding whether your consuming code must normalize a lone item into an array. I show paired samples, the failure they cause, a small normalization helper, and why an XML check says nothing about the resulting JSON shape.
Table of Contents
XML to JSON Single Element Object vs Multiple Elements Array: The Rule
XML has no array type. A feed with two <item> children is simply two sibling elements that share a name, and a feed with one is a single child. JSON forces a choice: a key holds either an object or an array. Every XML-to-JSON converter needs a rule to bridge that gap.
As of October 1, 2026, the site’s XML to JSON page says it groups repeated sibling elements with the same tag name into an array. That is the converter’s mapping rule, not a requirement of XML or JSON. RFC 8259 defines JSON objects and arrays but does not prescribe how XML must map to them, and the W3C XML specification says nothing about JSON at all.
The consequence follows directly. When the converter sees one item under feed, there is no repetition, so the value of item is the object for that single element. When it sees two, it collects them into an array. The page documents automatic grouping and optional attribute preservation, but it does not document a force-array setting, so I would not assume one exists. I also would not assume every other converter behaves the same way: some libraries always emit arrays, some never do, and some follow a rule like this one.
One Item vs Two Items: Paired XML and JSON Samples
Both samples below use a structured item, an item that contains an id child, so the lone value is visibly an object rather than a plain string. They contain no attributes, which keeps the attribute option out of the picture. If a sample is hard to read, run it through the XML Formatter first so the nesting is easy to see.
The JSON shown follows the rules documented on the site’s page. I did not independently verify it by running the interactive converter, so paste each sample into the tool yourself and compare the result with what I list here.
One item
<feed><item><id>1</id></item></feed>
{"feed":{"item":{"id":"1"}}}
Two items
<feed><item><id>1</id></item><item><id>2</id></item></feed>
{"feed":{"item":[{"id":"1"},{"id":"2"}]}}
The important difference is the value of item. In the first output it begins with { and is an object. In the second it begins with [ and is an array of objects. The key name, the parent and the child values are identical, yet the type of the value changed because the number of siblings changed.
Why the Shape Change Breaks Consumer Code
Both outputs are valid JSON, so nothing in a syntax check flags the difference. The trouble appears in code that assumes a collection. Consider a consumer written against a two-item sample:
const payload = JSON.parse(jsonText); const ids = payload.feed.item.map((item) => item.id); console.log(ids);
With two items, payload.feed.item is an array and the code logs both ids. With one item, it is a plain object, and plain objects have no map method, so the call throws a TypeError. A for...of loop over the lone object fails as well because the object is not iterable, and reading .length quietly gives undefined.
This kind of bug is intermittent, which makes it annoying. Your fixtures contain two items, the tests pass, and the code breaks on a quiet day when the feed contains exactly one. If an item were text-only, such as <item>1</item>, a lone value would be a string instead, and strings also lack map, so the same assumption fails in a different way.
If you want to try the snippet against both shapes, the JavaScript Editor runs code in the browser and shows synchronous console output. Only run code you wrote yourself, and keep the sample data fictitious.
Compare Real Outputs, Then Normalize Only If You Need an Array
Do not change the consumer based on my samples alone. Use your own feed and follow these steps:
- Collect a real feed response with one item, one with several, and, if the producer can send it, one with none.
- Convert each response and note the type at the path your code reads, here
feed.item. A JSON Formatter makes the opening{or[easy to spot. - Decide what your contract is. If the consuming code treats the field as a collection, it needs an array every time.
- Normalize at the boundary where the converted JSON enters your code, not in every function that reads it.
- Test the normalized result with zero, one and two items.
This is the same habit described in the guide on locating the records array before converting JSON to CSV: check the actual shape you hold before writing code that depends on it. Here is a small helper:
function toArray(value) {
if (value == null) {
return [];
}
return Array.isArray(value) ? value : [value];
}
const payload = JSON.parse(jsonText);
const items = toArray(payload.feed?.item);
console.log(items.length, items.map((item) => item.id));
Treating a missing value as an empty list is a policy choice, not a rule. If your feed must always contain at least one item, reject the payload instead:
const value = payload.feed?.item;
if (value == null) {
throw new Error('The feed must contain at least one item');
}
const items = Array.isArray(value) ? value : [value];
Array.isArray() inspects the runtime value, so it does not guess from the contents. MDN’s page, last modified July 10, 2025, lists it as widely available across browsers since July 2015, which makes it a safe check for current browsers (MDN reference).
Also test how your converter treats an empty element such as <item/>. I have not documented its output here, so run it and look before deciding whether toArray should treat that case specially.
What XML Validation Does Not Tell You About JSON Shape
It is tempting to think a validated feed guarantees a stable result, but each check answers a different question. The site describes its XML Validator as detecting parsing errors and malformed tags, which is a well-formedness check. The W3C XML 1.0 specification distinguishes well-formedness from validity, and validity against a DTD or schema is a stronger, separate check.
| Check | What it tells you | What it does not tell you |
|---|---|---|
| XML well-formedness | Tags are balanced and the document parses | Whether the data matches a schema, or how it maps to JSON |
| DTD or XSD validity | The XML follows declared structure rules | Which JSON shape a particular converter emits |
| JSON syntax check | The output parses as JSON | Whether a field is an object or an array in every case |
| Runtime test of your code | Your code handles the samples you tried | Inputs you did not try |
Even an occurrence constraint in an XML schema, such as allowing one or more items, describes the XML. It does not dictate that a JSON converter will emit an array for a single occurrence. The converter’s grouping rule decides that, which is why the output comparison in the previous section matters.
The JSON Validator checks syntax with the browser’s JSON.parse, and both {"id":"1"} and [{"id":"1"}] pass. Use these tools for what they do, then protect the shape with the boundary normalization and tests described above.
Edge Cases and Limits of XML-to-JSON Mapping
I kept attributes and mixed content out of the introductory examples on purpose. The site’s documentation describes optional @attributes and #text conventions, and enabling attribute preservation changes what an element looks like in JSON. If your feed uses attributes, run one-item and two-item samples with the same options you will use in production, and compare them before writing code.
Other limits apply to any XML-to-JSON mapping. It is not lossless: element ordering across different tag names, namespace prefixes and mixed text-and-element content can all be flattened or reshaped. Do not promise yourself that another converter, or a future version of this one, will produce the same shape. If the feed is something you depend on, ask the producer for a written contract and keep a few real sample files as regression fixtures.
When you need to go the other direction, the JSON to XML tool produces well-formed XML with a custom root element. Do not assume a round trip reproduces your original document; compare it against the source. For hand-editing sample output, the JSON Editor offers syntax highlighting, folding and JSON.parse syntax validation, but no tree view or JSON Schema validation, so shape checks still belong in your code and tests.
Frequently asked questions
Is it a bug that a single XML item becomes a JSON object?
No. XML has no array type, so the converter needs a rule. The site’s XML to JSON page says it groups repeated sibling elements with the same tag name into an array, which means a lone element has nothing to group and stays an object. The behavior is a mapping choice, not an error.
Does the site's XML to JSON converter have a force-array option?
The published page documents automatic grouping of repeated elements and optional attribute preservation. It does not document a force-array setting, so I would not rely on one. Normalize in your consuming code instead.
Should I always wrap the value in an array?
Only if your code treats the field as a collection. A helper that returns the value if it is already an array and wraps it otherwise is a common choice. Decide separately whether a missing value means an empty list or an error, because that depends on what your feed promises.
Can the XML Validator tell me whether item will be an array?
No. It detects parsing errors and malformed tags, which is a well-formedness check. It does not examine the JSON that a converter will later produce, so you still need to compare actual outputs.
Would a DTD or XSD solve the problem?
A schema describes allowed structure in the XML, including how often an element may occur. It does not control the converter’s JSON mapping, so a single permitted occurrence can still convert to an object. The converter’s grouping rule decides the shape.
Is Array.isArray safe to use in browsers?
MDN’s page, last modified July 10, 2025, identifies Array.isArray as widely available across browsers since July 2015. It checks the runtime value directly, which is why it is better than guessing from the value’s contents.
How do attributes change the one-item versus two-item behavior?
The site documents optional attribute preservation using @attributes and #text conventions, which changes the contents of each element’s JSON. The sibling grouping rule is described separately, so test both shapes with the same options you will use in production rather than assuming how the two interact.
Next steps
The XML to JSON single element object, multiple elements array difference is a mapping consequence, not a bug in your feed: repeated siblings become an array, and a lone element does not. Compare real one-item and two-item outputs, normalize at the boundary only if your code needs a collection, and decide deliberately what an empty result means. As a next step, paste a one-item and a two-item sample from your own feed into the converter, then add a test for each shape next to your Array.isArray check.
Related tools and resources on HTML Editor Online:
- XML to JSON
- XML Validator
- JSON to XML
- Why Is My JSON-to-CSV Export One Row Instead of One Row per Record?
- JSON Formatter
