Nothing is uploaded. When you paste text or open a file the converter reads it locally with the browser’s File API, parses it into memory, and serialises the XML on your device in JavaScript. There is no server, API, database or tracking in the processing path, so an API response, config file or any other sensitive data stays on your machine. The tool works offline once cached, and closing the tab discards everything. The one case where data touches the network is if you paste a remote URL for the tool to fetch — and even then the response is downloaded straight into your browser and never sent anywhere else. The only optional network use anywhere on the site is consent-gated advertising, which never sees your file.

The converter uses simple, well-known conventions. Every ordinary JSON key becomes an element, and its value becomes that element’s content. A key that starts with the attribute prefix — @ by default, switchable to _ or $ — becomes an attribute on the enclosing element, so {“book”:{“@id”:“7”}} yields <book id=“7”/>. When an element needs both attributes and text you put the text under the reserved #text key, and a #cdata key emits a <![CDATA[…]]> section for content you do not want escaped. A JSON array repeats the parent tag once per item, so several objects under “item” become several <item> elements; a top-level array, which has no single root, is wrapped in a configurable root element with a configurable item element per entry. null and undefined become empty self-closing tags.

Because different XML dialects expect different root names and conventions, the tool ships six presets that load a matching sample and configure the options for you. Generic produces a standard <root> with @ attributes; RSS 2.0 builds a podcast or news feed with a channel and repeated items; SOAP wraps a request in a soap:Envelope with the usual namespace attribute; Android strings.xml emits a <resources> block of localisation strings; Maven POM writes a Java project descriptor; and Sitemap generates a <urlset> of URLs for Google. Namespaces are handled as ordinary keys — write an xmlns declaration as an @xmlns attribute and prefixed element names like soap:Body as the key itself — because JSON has no built-in namespace concept.

After each conversion the tool converts the XML it produced back into JSON and compares it with your input, showing “Round-trip OK” when the two match and a “Lossy” warning when they do not — usually because of CDATA, mixed content or namespace edge cases that cannot be represented identically in both directions. The honest limits follow from XML itself: everything between tags is text, so numbers and booleans are not preserved as JSON types on the way back; comments and processing instructions are not generated; and XML namespaces have no native JSON equivalent, so they must be written as prefixed keys or xmlns attributes rather than inferred. Inputs are held in browser memory under a 25 MB cap, and loading a remote URL only works when that server sends permissive CORS headers.