Sample XML Generator
Generate a genuine XML document in seconds — seven content types, real namespaces, mixed content and CDATA, and an exact target file size. No flattened stand-ins. Runs entirely in your browser.
<?xml version="1.0" encoding="UTF-8"?>
<records>
<recordAsAttributes id="1" name="Sample Item 1" price="9.99" inStock="true"/>
<recordAsElements>
<id>1</id>
<name>Sample Item 1</name>
<price>9.99</price>
<inStock>true</inStock>
</recordAsElements>
<recordAsAttributes id="2" name="Sample Item 2" price="12.49" inStock="false"/>
<recordAsElements>
<id>2</id>
<name>Sample Item 2</name>
<price>12.49</price>
<inStock>false</inStock>
</recordAsElements>
<recordAsAttributes id="3" name="Sample Item 3" price="14.99" inStock="true"/>
<recordAsElements>
<id>3</id>
<name>Sample Item 3</name>
<price>14.99</price>
<inStock>true</inStock>
</recordAsElements>
</records>Quick Tips for the Right Test File
Features
Not Another SVG, and Not Another JSON
Sample SVG is XML with a job already picked out for it — every file it produces describes something to draw. This generator makes the opposite kind of XML: no fixed vocabulary, no assumed purpose, the same open-ended role XML has played for two decades of configuration files, SOAP messages, business documents and syndication feeds. That's also what separates it from Sample JSON — JSON is a data format with exactly one way to nest a value inside another, while XML offers a genuinely different set of structural tools: namespaces, attributes as a second place to put data, text and markup interleaved in the same flow. This generator exists specifically to exercise those XML-only capabilities, not to produce JSON-shaped data wearing angle brackets.
Comments & PIs rounds out that contrast from a different angle. Neither CSV nor JSON has any comment mechanism at all — a genuine, honest gap this library has documented on both of those tools' own pages. XML never had that problem: real <!-- --> comments and processing instructions like the <?xml-stylesheet?> declaration this file includes are both fully specified, decades-old parts of the format, which is exactly why this generator can use a genuine comment for padding instead of the visible workaround CSV and JSON need.
Two Valid Ways to Say the Same Thing
XML never forces a single answer to "does this fact belong in an attribute or an element," and real-world schemas genuinely disagree — SOAP favors elements almost everywhere, while many configuration formats lean heavily on attributes for anything short and scalar. Elements vs. Attributes builds the identical record both ways in the same file specifically so that difference stops being theoretical: a parser, a schema, or a hand-written extraction script either handles both correctly or it doesn't, and this is a fast way to find out which.
There's no universally correct answer here, and this generator doesn't pretend there is — attributes are compact and read well for short, scalar facts like an ID or a currency code, while elements handle repeated or structured values, and values that themselves need attributes, more naturally. The point of showing both isn't to argue one is better; it's to make sure whatever consumes this file has actually been tested against the one it's more likely to encounter in practice.
Text With Real Structure Living Inside It
Every other content-heavy format in this library — CSV's cells, JSON's strings — treats text as an indivisible unit; a string is a string, full stop. XML explicitly allows text and child elements to interleave inside the same parent, which is the entire mechanism behind rich text, inline formatting, and hyperlinks embedded directly in a sentence rather than bolted on as a separate field. Mixed Content is built around exactly that: real prose with genuine <bold> and <link> elements sitting inside the running text, not wrapping the whole paragraph from outside.
CDATA & Entities covers the other side of the same coin — sometimes a chunk of markup needs to travel through an XML document completely unmodified, and hand-escaping every angle bracket and ampersand in it would be both tedious and risky. A CDATA section solves that directly: everything inside it is literal character data until the closing marker, no escaping required at all.
The same file also lines up every real entity-reference style XML actually supports — the five predefined named entities, a numeric decimal reference, and a numeric hexadecimal reference — all decoding to ordinary characters despite looking structurally different on the page. A parser that only recognizes one form has a real, specification-level gap, not just an unusual formatting preference to shrug off.
Who Actually Needs a Real Test XML
Backend developers building or hardening an XML parsing or transformation pipeline need Elements vs. Attributes and XML Namespaces specifically, since those two cover the modeling ambiguities that most commonly trip up a schema or converter written against only one real-world example. Developers building a document editor or CMS with rich-text export need Mixed Content to confirm inline formatting round-trips correctly, not just plain paragraphs. Anyone integrating with a feed reader, aggregator, or RSS consumer needs RSS Feed specifically — a realistic, recognizable structure a real parser actually expects, not an approximation.
QA teams covering an XML-import feature end-to-end have the broadest need of all here: a parser that handles Repeated Elements correctly can still fail entirely on its first namespace, its first CDATA block, or its first genuinely mixed-content paragraph. Working through each content type deliberately, rather than testing against one convenient shape repeatedly, is what actually surfaces those gaps before real-world data does.
Repeated Elements Is the Baseline, Not an Afterthought
It's worth naming Repeated Elements directly rather than treating it as too simple to mention — a growable collection of same-shaped child elements is genuinely the most common real-world XML pattern of all, the structure behind everything from a product catalog to a list of search results. Every other content type in this generator adds one specific complication on top of that baseline; none of them replace the need to confirm the baseline itself parses correctly first.
Where This Tool Isn't the Right Pick
If the test needs a rendered image rather than structural markup, Sample SVG is the right generator for that — this one produces data-shaped XML with nothing to visually render. If the test specifically needs JSON's simpler, more constrained structure instead, Sample JSON is the more direct fit. And if you already have real XML and need it converted rather than a new sample generated, XML to JSON and XML Formatter handle that directly.