← All tools
XML Tools

XML ↔ XSD Converter

Generate an XSD schema from a sample XML document, or a sample XML document from an XSD schema — either direction, entirely in your browser.

Use the tool ↓
XML input 0 chars
XSD output 0 chars
Paste an XML document to generate its schema.

About this tool

An XSD (XML Schema Definition) describes the shape a family of XML documents is allowed to take: which elements can appear, in what order, how many times, which attributes each one carries, and what type of data belongs in each — a string, an integer, a date. XML and XSD are two views of the same structure, one a concrete example, the other the rule set behind it, and going from either one to the other is a common, tedious-by-hand task. This tool covers both directions.

XML → XSD walks the whole document you paste in once. For every element name it sees, it records the attributes that appear on it, the child elements inside it and the order they show up in, and — for elements that hold plain text rather than nested elements — the text itself, which it uses to guess a data type. If every <tools> element in your sample contains a plain integer, the generated schema types it as xs:integer rather than the always-safe fallback of xs:string. The same reasoning applies to decimals, booleans, dates, and full timestamps. Occurrence rules come from comparing multiple instances of the same parent element, when your sample has more than one: a child missing from at least one instance is marked optional (minOccurs="0"), and one that appears more than once inside any instance is marked repeatable (maxOccurs="unbounded"). An attribute is marked required only if it was present on every occurrence of that element in your sample. Because all of this is inferred from a single example, treat the result as a solid first draft to review, not a guaranteed-final contract.

XSD → XML works the other way: it reads the element and type definitions in your schema and builds one representative XML document that satisfies them. Required and optional elements are both included, since the goal is a complete example rather than the smallest possible valid document. An element that can repeat (maxOccurs="unbounded") is shown twice, to make the repetition visible; a bounded repeat count generates that many, capped at three for readability. Element and attribute values are filled with a placeholder appropriate to the declared type — an integer becomes 0, a boolean becomes true, a date becomes a sample date — or, where a simpleType restricts values to an enumeration, the first listed enumeration value. Self-referencing schemas (an element type that contains itself, directly or through a chain of types) are expanded a bounded number of times so the output stays finite and readable.

Everything runs locally in your browser using the built-in XML parser; nothing you paste is transmitted anywhere.

XML valueInferred XSD typeXSD typeGenerated sample value
15xs:integerxs:integer0
49.99xs:decimalxs:decimal0.0
true / falsexs:booleanxs:booleantrue
2026-01-15xs:datexs:date2026-01-01
2026-01-15T09:30:00Zxs:dateTimexs:dateTime2026-01-01T00:00:00Z
anything elsexs:stringxs:stringstring

How to use it

  1. 01

    Pick a direction

    XML → XSD to generate a schema from an example, or XSD → XML to generate an example from a schema.

  2. 02

    Paste your input

    For XML → XSD, include more than one instance of any repeating element for accurate occurrence rules. For XSD → XML, paste the full schema, including any global type definitions it references.

  3. 03

    Check the result

    The output updates as you type. If the input can't be parsed, the status bar explains what went wrong.

  4. 04

    Copy the output

    Copy the result into a .xsd or .xml file and adjust anything that needs a human's judgment.

Example

XML
<product id="1042">
  <name>Nesake</name>
  <tools>15</tools>
  <categories>
    <category>JSON</category>
    <category>Security</category>
  </categories>
</product>
XSD
<xs:element name="product" type="ProductType"/>

<xs:complexType name="ProductType">
  <xs:sequence>
    <xs:element name="name" type="xs:string"/>
    <xs:element name="tools" type="xs:integer"/>
    <xs:element name="categories" type="CategoriesType"/>
  </xs:sequence>
  <xs:attribute name="id" type="xs:integer" use="required"/>
</xs:complexType>

<xs:complexType name="CategoriesType">
  <xs:sequence>
    <xs:element name="category" type="xs:string"
      maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

Common use cases

Documenting an existing format

Turn a real XML file from a legacy system into a formal schema nobody ever wrote down.

Validating incoming data

Generate a starting schema to catch malformed XML before it reaches your application.

API contract drafts

Produce a first-pass XSD for a SOAP or XML API from a sample request or response.

Sample payloads from a spec

Turn a schema you were handed into a concrete XML example for docs, tests, or a mock server.

Testing an XML parser

Generate realistic fixture files straight from the schema your parser is meant to accept.

Onboarding new data sources

Quickly understand the shape of an unfamiliar XML feed before writing a parser for it.

Frequently asked questions

How are data types decided?

The tool looks at every text value found for a given element or attribute across your sample. If all of them match a pattern — whole numbers, decimals, true/false, a date, or a full timestamp — it uses that XSD type. If even one value doesn't fit, it falls back to xs:string, which always validates.

Why does an attribute come out as optional when it's actually always present?

An attribute is marked required only if every occurrence of that element in your pasted sample had it. If your sample happens to include an instance without it, or only has one instance to judge from, add more representative examples and regenerate.

Does this handle deeply nested XML?

Yes. The tool walks the full tree recursively and creates a named complex type for every element that has attributes or child elements, however deep the nesting goes.

What happens with elements that mix text and child elements?

XSD's mixed-content model is more involved than a straightforward element tree. This tool covers the common case of text-only elements and elements with only children or attributes; a fully mixed element (text alongside child elements) will validate against the generated schema's children and attributes, but the loose text between them isn't separately typed.

Why does the generated XML include every optional element?

The XSD → XML direction aims for a complete example rather than the smallest valid document, so it includes both required and optional elements and attributes. Delete anything you don't need for your case.

What values does it use for generated elements?

A placeholder appropriate to the declared type: 0 for integers, true for booleans, a sample date for date types, and so on, or the first listed value when a type restricts the field to an enumeration. They're meant to be replaced with real data.

What happens with a schema where a type refers to itself?

Self-referencing structures, like a tree or a category with subcategories of the same type, are expanded a bounded number of levels so the generated XML stays finite and readable, rather than recursing indefinitely.

Does my XML or XSD get uploaded anywhere?

No. Parsing and generation both happen in your browser using the built-in XML parser. Nothing you paste is sent to a server.

Related tools

Working with structured data? These pair well with this converter.

JSON ↔ XML Converter

Move the same payload between JSON and XML in either direction.

JSON Schema Validator

The JSON-world equivalent of validating a document against a schema.

JSON to TypeScript

Generate types from an example instead of a schema.

All developer tools

Browse the full hub of local-first, no-upload utilities.