XML to TypeScript Interface Converter — Zero-Upload

Interfaces that match the document you actually have

TypeScript's job is to describe a shape, and XML documents are shapes with a history: elements that were added in 2009, attributes nobody remembers authorizing, and namespaces layered by successive integrators. This converter reads the document in front of it and describes exactly that. Nested elements become their own exported interfaces — <channel> inside <rss> becomes Rss and Channel — and repeated siblings become arrays, so the types fit the wire format rather than an idealized version of it.

The naming path is deliberate: tag names are PascalCased for interface names and camelCased for properties, and the original tag or attribute is preserved alongside each rename. When a runtime error eventually points at a field, that recorded original name is the difference between a five-second fix and an afternoon of grepping a decade of XML.

One more note on arrays: TypeScript cannot express one-or-many without a union, and neither can your document. The generator types what it sees and leaves the union to you, which is the correct default — a T[] that is sometimes wrong is worse than an honest T plus a comment.

What the types encode — and what they honestly cannot

Instance-based inference has a boundary this tool states instead of hiding: it can only type what your sample shows. An optional element that happens to be absent from the pasted document will not appear in the interfaces; a field that appears once will be typed as a scalar even if some documents repeat it. The fix is the obvious one — paste the richest instance you can find, or paste two documents and reconcile — and the output is plain interfaces, so hand-editing the merged result is trivial.

Mixed content is concatenated into a #text property rather than discarded, empty elements infer null so the union tells the truth about absence, and ISO-8601 timestamps map to string with a comment, because the honest type for text you cannot verify is string — not Date, not any, string.

The workflow that sticks: keep the richest sample document in the repo, regenerate whenever the feed changes, and treat the diff as the changelog. Because the interfaces are exported and plain, they compose into existing types with Pick and Omit instead of forcing a generator into the build pipeline. The types describe the wire; the wire describes itself; nothing in between needs to be trusted.

Why offline conversion matters for XML payloads with PII

The XML documents that need converting most — SOAP responses, vendor exports, internal reports — are precisely the ones that should not be pasted into a random website. This converter runs entirely in a Web Worker inside your browser: there is no upload call in the code path, no analytics payload carrying your document, and no backend that could log it. Once the page is loaded it works on a plane, which is the operational proof of the privacy claim. Documents full of PII and internal identifiers are precisely what this tool is built to keep local.

A 3-second watchdog bounds every conversion so a deeply nested document cannot lock the tab, and parse failures surface as line-and-column diagnostics — mismatched tags, unknown entities, unterminated CDATA — instead of a stack trace or, worse, silently wrong interfaces.

How do I convert XML to TypeScript interfaces?

Paste the XML document into the input pane and the interfaces generate live as you type. The root element becomes the root interface, nested elements become their own exported interfaces, and you can set the root name in the workspace before copying the output.

What happens to XML attributes?

Attributes become properties with renamed, valid identifiers — @id becomes id — and the original attribute name is preserved alongside so the mapping back to the document is explicit. Attribute values are conservatively sniffed: true/false and round-trippable numbers get typed accordingly, everything else is string.

Why is my array field typed as a single object?

Because the document you pasted contains one occurrence of that element — the converter types what it observes, honestly. Find a document where the element repeats, or paste a second sample, and the field infers as an array. This beats the alternative: a converter that guesses every field might repeat produces T[] everywhere and types nothing usefully.

Are namespaces and prefixes preserved?

Tag names are kept exactly as written through parsing — atom:feed stays atom:feed — and then renamed to valid TypeScript identifiers with the original recorded. Silently stripping prefixes is how two different elements collapse into one field, so it never happens here.

Is my XML sent to a server?

No. Parsing and interface generation run in a Web Worker in your browser; there is no upload endpoint, nothing is logged, and the tool works offline once loaded. Malformed documents get precise line-and-column errors rather than a partial or wrong output.