How do you keep an XML attribute ID such as 007 in JSON?
Answer: Keep the ID as a JSON string. ParseBloom maps <item id="007">Notebook</item> to {"item":{"_attributes":{"id":"007"},"_text":"Notebook"}}. Converting "007" to a number would remove the leading zeros.
Where each piece goes
The attribute and the element's direct text occupy separate properties. The keys _attributes and _text describe this converter's output, not a universal XML-to-JSON standard. Check a different converter's contract before swapping tools.
Four inputs you can paste into the converter
These are synthetic test cases, not imported customer records. Each output was read from the hosted converter on 26 October 2026. Whitespace below is compacted for comparison; the tool displays indented JSON.
<item id="007">Notebook</item>{"item":{"_attributes":{"id":"007"},"_text":"Notebook"}}The ID remains three characters long. Text is preserved separately from the attribute.
<r><id>007</id><price>12.50</price><flag>false</flag></r>{"r":{"id":"007","price":"12.50","flag":"false"}}All three values are strings. No numeric or boolean conversion happens in this tool, so the price keeps its trailing zero.
<x id=""/>{"x":{"_attributes":{"id":""}}}An empty string differs from a missing id. Check for property presence when that distinction matters.
<item id="007"><id>008</id></item>{"item":{"_attributes":{"id":"007"},"id":"008"}}The attribute is item._attributes.id; the child is item.id. A consumer that reads only item.id gets a different identifier.
Read the attribute by its exact path
If your XML contract says the identifier is an attribute, read that attribute explicitly. Avoid a numeric parse or a fallback to a child element with the same name.
const attrId = result.item?._attributes?.id;
if (typeof attrId !== "string") {
throw new Error("Expected an XML id attribute");
}
// attrId is "007" for the first and fourth test cases.The empty-attribute case passes the type check because "" is a string. Add attrId.length > 0 if your own schema forbids blank IDs. This is a consumer-side validation choice, not a conversion setting.
Keep the original XML when exact round trips, comments, or mixed-content order matter. This page tests four value-mapping cases, not a lossless XML archive.
Check your own document
Paste your XML into the browser-local converter, then inspect the exact JSON path and value type your receiving code uses. Also test one element with and without the attribute. For repeated child elements, see the single-versus-array guide.
The examples answer practical questions also raised in public developer discussions about leading zeros and where attributes belong in JSON. They demonstrate this tool's behavior; they do not assume that other libraries use the same keys.