GraphQL to XML Converter
Paste a GraphQL schema or query. Get clean XML back.
What this tool does
If you have ever had to document a GraphQL API for a team that only works in XML, or wire a GraphQL schema up to a legacy SOAP client, you know the awkward part: GraphQL types don't translate one-to-one. Paste your schema or query here and you get back well-formed XML in a single pass. A handful of type definitions, a full SDL file, or a concrete query with arguments — same result: a complete XML document that mirrors the shape of the data.
The converter knows the GraphQL spec, not just the surface syntax. Scalar defaults line up the way you would expect — String becomes text, Int and Float become numeric text, Boolean becomes true/false, and ID becomes a string value. Non-null markers (String!) and list markers ([OrderItem!]!) are respected: a required list shows up as a container element with one child per item, and nullable fields with no value come through as empty elements so the shape of the document stays consistent.
Beyond the built-ins, the tool handles the rest of the type system too. input types turn into nested elements, enum values come through as string text, interface and union types resolve to their underlying concrete shapes, and fragments (named or inline) are pulled in so the output is flat and self-contained. Custom scalars like DateTime, Date, and JSON are emitted as ISO-8601 or stringified values. If you paste a query with arguments, the arguments are preserved as part of the top-level element so the XML is a faithful record of the request, not just a blob of data.
How to use it
Three steps. Works the same whether you paste a single type or a full schema with queries.
Paste your GraphQL (or try the sample)
Drop the GraphQL into the left editor as-is. A single type, a full SDL file with input/enum/interface/union, or a concrete query with variables — all fine. Hit Load Sample if you want a realistic shape to play with first.
You do not need to strip comments or reformat the SDL syntax. Leave it the way your editor wrote it — triple-quoted docstrings and hash comments are both fine.
Hit Convert
Click the green Convert button. The tool reads the schema (or query), resolves fragments and list/non-null markers, and builds the XML in one pass. A short loading indicator runs while the conversion happens.
Copy the XML
The right panel fills with indented, well-formed XML that any standards-compliant XML parser will accept. Copy it straight into your SOAP request, documentation, fixture, or XSD example.
When this actually comes in handy
XML-based docs for a GraphQL API
Internal docs or partner documentation that lives in XML (DITA, DocBook, XSD-backed reference). Paste the schema, get example XML payloads that match the real types — no hand-translation.
Generating XML fixtures from a schema
Contract tests, snapshot tests, or a mock server that speaks XML. Feed it the schema you already have and get consistent fixture XML with every list, nullable, and nested type in the right place.
Bridging to legacy SOAP clients
A partner system only accepts XML payloads but your backend speaks GraphQL. Paste the query and response type and get a starting-point XML body to drop into the SOAP request.
Schema migration & analysis
Moving off GraphQL onto an XML-based API (or just comparing the two shapes). Get a side-by-side XML version of every type so reviewers who do not read SDL can follow along.
Common questions
How are type, input, enum, interface, and union handled?
type and input become element containers with one child per field. enum values come through as plain string text (the enum name, uppercase, exactly as declared in the SDL). interface resolves to its fields plus any implementing type's fields when we know the concrete type. union resolves to the matched member's shape. See the GraphQL type language reference for the full rules.
What defaults are used for String, Int, Float, Boolean, and ID?
String and ID become text content. Int is a plain integer. Float is a decimal number with no trailing zeros. Boolean is the lowercase text true or false. These match the scalar definitions in the GraphQL spec so the output round-trips cleanly through an XML parser.
How are non-null (!) and list ([T]) markers treated?
Non-null (String!) is treated as a field that must appear — nullable fields with no value come through as empty elements so the document shape stays predictable. Lists ([OrderItem!]!) become a container element with one child per item, named after the element type — e.g. items: [OrderItem!]! turns into <items><OrderItem/><OrderItem/></items>. Nested lists ([[Int]]) nest the same way.
Are fragments resolved?
Yes. Named fragments (...OrderFields) and inline fragments (... on Order { ... }) are resolved inline so the XML is flat and self-contained. You do not need to paste the fragment definitions separately — if they are in the same block, the tool wires them up. This matches the normal query-execution model, where fragments are spread into the selection set before the response is built.
What about custom scalars like DateTime?
Well-known custom scalars (DateTime, Date, Time, UUID, JSON) are emitted as ISO-8601 text or stringified values by convention — matching what most scalar libraries do. Unknown custom scalars fall back to string text so nothing is silently dropped. If you need a specific format, post-process the XML or rename the scalar.
Can I paste a query with arguments, not just a schema?
Yes. Paste a query with variables and arguments — e.g. query GetOrder($orderId: ID!) { order(id: $orderId) { ... } } — and the arguments come through as attributes on the top-level element. The selected fields dictate which parts of the response shape are serialised, so the XML matches what the query would actually return, not the whole type.
Other tools you may need
GraphQL to XML is one piece of the puzzle. These tools pair well with it: