Password Generator
Cryptographically random passwords with a live entropy meter.
Utilities & Converters
XML to JSON and back, with attributes preserved.
| XML feature | In JSON |
|---|---|
| Attributes | Convention — usually an @ prefix |
| Namespaces | Flattened into the key, or lost |
| Comments | Lost |
| Mixed content | Awkward — #text alongside children |
| Element order | Preserved only within arrays |
| Schema and types | Lost — everything is a string |
The single-child problem is the one that bites in practice. One <item> converts to an object; two convert to an array. Code that expects an array breaks whenever the data happens to contain exactly one — a bug that appears in production and never in testing.
Real types. JSON distinguishes the number 5 from the string "5" and has a genuine boolean and null; XML has text and whatever a schema says it means.
Converting JSON to XML therefore loses type information unless you add schema attributes, which most converters do not.
JSON also has no equivalent of an attribute, so going the other way every property becomes an element — which produces valid XML that no XML-native consumer would have designed.
Usually because a system you do not control speaks the other format. That is a good reason.
A poor reason is preferring one syntactically. Converting an XML document to JSON to make it easier to read discards the schema and the namespaces that made it verifiable.
If the XML has an XSD and the data matters, the conversion loses your ability to validate it. That is a real cost and it is invisible until something malformed gets through.
By convention, usually with an @ prefix — so <user id="5"> becomes {"user":{"@id":"5"}}. It is a convention rather than a standard, so different tools differ.
Because XML has no way to say "this is a list of one". One element converts to an object, two to an array, so code expecting an array breaks exactly when the data has one item — in production, never in testing.
No. JSON has no comment syntax at all, so XML comments are dropped in the conversion.
Going XML to JSON, yes — XML text has no types without a schema, so everything arrives as a string. Going JSON to XML also loses types, since XML has no native number or boolean.
Not if the XML has a schema. Converting discards the XSD and namespaces that let you validate the data, and that loss is invisible until something malformed gets through.