Generate XSD from XML

How to generate an XSD from XML

To convert XML to XSD, paste or drop a document — this XSD schema generator infers the schema from the element structure in seconds, so you never write it by hand. You can generate a schema from XML on any device, with no install and no upload.

1. Add your XML — paste or drop a document. Add more samples of the same structure to infer optional fields; every document is parsed locally in your browser and never leaves your device.
2. Pick the output style — Single file inlines every type, while Separate types emits named complexType definitions.
3. Generate and export — copy the schema or download it as a .xsd file, ready for validators and code generators.

Why generate schemas locally

This XML to XSD generator runs entirely in your browser, so there is no file size limit imposed by a server, no signup, and your data is never uploaded or stored. It works offline after the page is loaded, and the same engine runs on Windows, macOS and Linux.

The inferred schema captures element order, repeated elements (maxOccurs="unbounded"), attributes, namespaces and simple types such as integer, decimal, boolean, date and dateTime. Mixed or unknown content is emitted as xs:anyType so the result stays valid. Feed the generator several representative samples and it will also detect optional elements (minOccurs="0") and optional attributes, and explain every decision in a diagnostics panel below the result.

Example: XML in, XSD out

This is the kind of document the generator handles best — a namespace declaration, nested elements, repeated elements, and an attribute. Paste it into the box above and press Generate XSD to see the live result.

<?xml version="1.0" encoding="UTF-8"?>
<order:orders xmlns:order="https://example.com/order">
  <order:order id="1001">
    <order:customer>Ada Lovelace</order:customer>
    <order:shipped>false</order:shipped>
    <order:item>
      <order:sku>BOOK-001</order:sku>
      <order:qty>2</order:qty>
      <order:price>19.95</order:price>
    </order:item>
    <order:item>
      <order:sku>PEN-014</order:sku>
      <order:qty>5</order:qty>
      <order:price>1.20</order:price>
    </order:item>
  </order:order>
</order:orders>

order:orders is a QName: prefix order, namespace URI https://example.com/order, local name orders. XSD element declarations must use local names (the name attribute is an NCName and cannot contain :), so the generator records the URI once in targetNamespace and emits unprefixed names. The repeated item element gets maxOccurs="unbounded", and xs:string, xs:boolean, xs:integer and xs:decimal are inferred from the sample values:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="https://example.com/order"
  elementFormDefault="qualified">
  <xs:element name="orders">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="order">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="customer" type="xs:string"/>
              <xs:element name="shipped" type="xs:boolean"/>
              <xs:element name="item" maxOccurs="unbounded">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="sku" type="xs:string"/>
                    <xs:element name="qty" type="xs:integer"/>
                    <xs:element name="price" type="xs:decimal"/>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute name="id" type="xs:string" use="required"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Generate XSD from multiple XML samples

A single sample cannot prove a field is optional. Paste two orders into separate sample boxes — the second one without shipped and with an integer price — and press Generate XSD. The generator merges the structure across samples:

<order:order id="1001">
  <order:shipped>false</order:shipped>
  <order:price>19.95</order:price>
</order:order>

<order:order id="1002">
  <order:price>20</order:price>
</order:order>

The merged result marks shipped as minOccurs="0" (missing from one instance) and promotes price from xs:integer to xs:decimal (both forms appear). The diagnostics panel under the output shows exactly why:

• `shipped`: appears in 1 of 2 order instances → minOccurs="0"
• `price`: values match integer + decimal → typed xs:decimal
• Only one XML sample provided… — this note disappears once you add a second sample.

XML → XSD with namespaces

In XML, <order:orders xmlns:order="https://example.com/order"> is a QName with three parts: the prefix order, the namespace URI https://example.com/order, and the local name orders. XSD does not keep prefixes in declarations — xs:element name values are NCNames, so a colon there is invalid. The generator maps the input's prefixes and URIs into the two schema mechanisms that actually carry namespaces:

• targetNamespace — the namespace URI of the root element is recorded once on xs:schema. With elementFormDefault="qualified", every element declaration in the schema belongs to that namespace, exactly like the prefixed elements in your input document.
• xmlns declarations — emitted only where the schema itself needs to reference another namespace. Element and attribute declarations use local names.

You can override the inferred namespace in the Advanced options: set targetNamespace to your own URI. If it differs from the input's namespace, the generator warns that the result will no longer validate the original document.

XSD generator options explained

• XML samples — add several documents with the same structure. The generator merges them to infer minOccurs="0" and attribute use, and the diagnostics panel explains each decision.
• Single file vs Separate types — Single file nests every type inside its parent element, which keeps the schema compact and easy to read. Separate types emits named xs:complexType definitions and a root element that references them, which is closer to what you would write by hand and easier to reuse across schemas.
• targetNamespace — sets the targetNamespace attribute on the generated xs:schema. Leave it empty to reuse the namespace of the input document, or set it to apply the schema to a namespace of your choosing.
• elementFormDefault — qualified means locally declared elements belong to the targetNamespace; unqualified means local elements carry no namespace. Most modern schemas use qualified.
• XSD version 1.0 vs 1.1 — 1.1 adds features like assertions and stronger wildcards, but not every validator supports it. The generator marks the output with a comment when 1.1 is selected; pick 1.0 for maximum tool compatibility.

Common errors when generating XSD from XML

• "XML parse error" — the input is not well-formed XML: an unclosed tag, two root elements, or stray text outside the root. Fix the document and press Generate again; the error message points at the first offending construct the browser parser reports.
• minOccurs and missing elements — cardinality is inferred from the samples you provide. An element that appears more than once under the same parent is emitted with maxOccurs="unbounded"; an element that is missing from some instances of its parent gets minOccurs="0". Feed the generator documents that both include and omit the field — a single sample cannot prove a field is optional.
• Attribute required vs optional — an attribute present on every occurrence of its element is emitted with use="required", otherwise use="optional". Attribute values are always typed xs:string, because the generator cannot know your value rules from samples alone.
• Names in the generated XSD never contain ":" — XSD names are NCNames, so a name like order:orders would be invalid. The generator keeps the namespace URI in targetNamespace (and xmlns declarations where the schema itself references another namespace) instead of keeping prefixes inside name attributes.
• Mixed or unknown content — when an element contains both text and child elements, or a value matches no known pattern, it is emitted as xs:anyType so the schema always stays valid, even when the input is unusual.
• Namespace URIs with spaces — some vendor files contain namespace URIs with whitespace, which parsers reject. The tool percent-encodes them before parsing so generation still succeeds.

Frequently asked questions

What is an XSD?

An XSD (XML Schema Definition) describes the structure, order and data types of an XML document. It is the modern replacement for DTDs and is what validators and code generators use to check or consume XML.

Why should I provide several XML samples?

A single sample cannot prove a field is optional. Provide two or more samples and the generator detects elements missing in some instances (minOccurs="0"), attributes that are not always present (use="optional"), and value types that change between samples. The diagnostics panel under the output explains each decision.

What is the difference between an XML schema and a DTD?

A DTD is the older, simpler grammar with limited types and no namespace support. An XSD is written in XML itself and adds data types, namespaces and precise cardinality, which is why it is the standard choice today.

How is this different from the old xsd.exe command line tool?

xsd.exe ships with Visual Studio, runs on Windows only, and is not always installed in newer Visual Studio versions. This generator runs in any browser on Windows, macOS or Linux with no install; the same controls are exposed as on-page options.