XML to XSD Generator — Infer a Schema from Sample XML

Paste XML where every optional element appears at least once and every repeating element appears at least twice — a single occurrence can't prove either possibility — choose Russian Doll or Venetian Blind, and press Convert. Tighten the result by hand afterward: add enumerations, patterns and length facets a sample can't reveal.

By repetition and presence across every instance of an element it finds anywhere in the document: a child element or attribute that shows up in EVERY instance of its parent is marked required (or minOccurs="1"); one that's missing from even a single instance becomes optional (minOccurs="0"). maxOccurs becomes "unbounded" the moment any single parent instance contains two or more occurrences of that child — a document with only one <item> gives no evidence it can repeat, so that field stays maxOccurs="1" until you paste a sample where it actually repeats. This is exactly why a single-instance sample understates a schema: the inference is honest about what it saw, not about what your format actually allows.

Three deliberate safety nets, all designed to avoid inferring a type that would reject legitimate values: a value with a leading zero ("007", a product or postal code) stays a string, because xs:integer would silently accept "7" as equivalent and drop the leading zero's meaning; a field that mixes whole numbers and decimals across instances ("1" in one record, "1.5" in another) widens to xs:decimal rather than picking one and failing on the other; and a field that mixes numeric-looking values with anything else at all — even one non-numeric outlier in the sample — falls all the way back to xs:string, since a real production field that occasionally isn't numeric will keep not being numeric after you deploy the schema.

A sample proves what values CAN look like, never the full space of what they're ALLOWED to look like — that gap is the honest limit of any sample-driven generator, this one included. Specifically out of reach: enumerations (a status field with three sampled values might legally have thirty), pattern constraints (a product code's exact format), length and numeric-range facets (minLength, maxInclusive and friends), the choice between xs:sequence and xs:choice (a sample can't show "exactly one of these two children," only what happened to appear), xs:key/xs:unique identity constraints, and — the subtlest one — which ALWAYS-present elements in your sample are actually optional in the real format, since "present in every instance of a one-document sample" and "required by the format" are not the same claim. Treat the output as a typed skeleton to tighten by hand, not a finished contract.

Russian Doll (the default) nests every type anonymously inline inside the element that uses it, which reads well for a one-off document you're not going to reuse pieces of and keeps the whole schema in one visual block. Venetian Blind instead declares one named, global xs:complexType per element name — CustomerType, ItemType — and references those types by name, which pays off the moment a type needs reusing elsewhere in the schema, or when a large vocabulary benefits from types you can find by name instead of by scrolling through nested indentation. A third style some tools offer, Salami Slice (every ELEMENT, not just every type, declared globally and referenced), isn't offered here — it's the least common of the three in practice and adds a namespace-collision hazard this tool would rather avoid by default.

A default xmlns="..." declaration on the root element becomes the schema's targetNamespace (with a matching xmlns and elementFormDefault="qualified" added), so an unprefixed document with a default namespace produces a schema that validates it correctly. Elements or attributes that use a NAMESPACE PREFIX (soap:Envelope, xsi:type) are handled more conservatively: the schema uses the local name only (Envelope, not soap:Envelope), and the status message tells you prefixed names were found — you add an xs:import for each additional namespace and wire up the prefix-to-namespace mapping by hand, since a sample alone doesn't carry enough information to safely reconstruct a multi-namespace import graph.