XML {{ workflowModeLabel }} Snapshot
{{ workflowSummaryFigure }}
{{ workflowModeLabel }} target -> {{ primaryWorkflowOutput.label }} - {{ metrics.recordPathDisplay || 'Auto record path' }}
{{ workflowModeLabel }} {{ metrics.elementCount.toLocaleString() }} elements {{ metrics.attributeCount.toLocaleString() }} attributes {{ metrics.uniqueTags.toLocaleString() }} unique tags Depth {{ metrics.maxDepth }} Preview trimmed Tree trimmed
{{ warning }}
XML Attrs Depth {{ xmlTransformStage.depthLabel }} {{ xmlTransformStage.outputLabel }}
{{ workflowModeGuidance }}
{{ input_text.length.toLocaleString() }} chars
Paste XML, drop one XML/TXT document, or use Browse file; outputs update automatically for records, JSON/JSONL, CSV/TSV, SQL, schema, and tree views.
Auto favors repeating structured nodes; choose a path when the table looks wrong.
Use catalog>book or catalog/book; prefixes and case are ignored.
Drop XML or TXT onto the textarea.
Turn on to keep id, code, and namespace attribute values.
{{ include_attributes ? 'On' : 'Off' }}
Turn off for structure-only exports that ignore text content.
{{ include_text_nodes ? 'On' : 'Off' }}
Enable for indented XML; disable when leading or trailing spaces matter.
{{ trim_text ? 'On' : 'Off' }}
Use for prose-light datasets; turn off for preformatted text.
{{ collapse_text_whitespace ? 'On' : 'Off' }}
Leave off when all XML text must remain strings.
{{ coerce_types ? 'On' : 'Off' }}
Common choices: @, attr_, or blank for no prefix.
Default #text is common for XML-to-JSON output.
Accepted range: 2 to 8 spaces.
spaces
Accepted range: 25 to 1000 rows.
rows
Accepted range: 3 to 12 levels.
levels
Use letters, numbers, or underscores, for example xml_records.
{{ header }} Copy
{{ cell }}
No record rows detected
Choose another record path when the XML has a different repeating node.
{{ csvText }}
{{ tsvText }}
{{ prettyXml }}
{{ htmlTable }}
{{ markdownTable }}
{{ sqlInsertText }}
{{ treeText }}
Path Count Attributes Child tags Text Copy
{{ row.path }} {{ row.count.toLocaleString() }} {{ row.attributes }} {{ row.childTags }} {{ row.hasText ? 'Yes' : 'No' }}
Schema summary unavailable
Paste or load well-formed XML to build tag, attribute, and child-node rows.
Customize
Advanced
:

Introduction

XML is still common wherever systems need a self-describing document rather than a simple row file. Product catalogs, bank exports, SOAP responses, build configuration, RSS-style feeds, and partner integration files often keep data in nested elements, attributes, and text nodes. That structure is flexible, but it also means the useful record may be hidden under wrappers, repeated sections, namespaces, or mixed content.

A conversion is not just a change of file ending. XML starts as a tree: one root element contains branches, branches contain child elements, and attributes can attach facts directly to a start tag. A spreadsheet-style result needs a record path, which is the repeated element that should become one row. A tree-style result keeps the document shape, which is better when the hierarchy matters more than a flat table.

Common XML shape decisions before conversion
XML situation Conversion question Common mistake
One repeated business object Which element is one useful record? Selecting the wrapper instead of the repeated item.
Nested repeated lists Should rows represent parent objects or child details? Flattening line items without keeping order-level context.
IDs stored as attributes Should attributes become fields? Dropping identifiers because only child elements were reviewed.
Mixed text and child elements How should text fragments be preserved? Treating prose, labels, or notes as empty structure.

Well-formed XML has one document element and properly nested tags. That only proves the syntax can be parsed. It does not prove that the chosen rows are the right rows, that namespace prefixes identify the same business meaning, or that numeric-looking values can safely become numbers. Branch codes such as 0017, for example, are text identifiers even though they look numeric.

XML tree parsed through a record path into row outputs and full-tree outputs
A good XML handoff separates the full document tree from the repeated branch that should become records.

The safest conversion starts by reading the document shape, then choosing the path and text policies that match the destination. A clean table, JSON object, or SQL test insert is useful only if the selected records still carry the identifiers, parent context, and text values that made the XML meaningful.

How to Use This Tool:

Use the first pass to understand the XML shape, then refine the record path and conversion options before copying or downloading the final output.

  1. Choose Workflow target for the output you want first. Data table, JSONL records, SQL inserts, and HTML/Markdown table need record rows; JSON tree, Pretty XML, and Integration handoff can still be useful when no row path exists.
  2. Paste XML into XML document, drop one XML or TXT file onto the text area, or use Browse file. Load sample is useful for checking the result tabs before using private or partner data.
  3. Start with Record path set to auto detect. If Record Fields shows no rows, too few rows, or rows that represent the wrong entity, choose one of the suggested paths or enter a Custom path such as catalog>book.
  4. Open Advanced when field meaning depends on attributes, text fragments, whitespace, type coercion, indentation, preview size, tree depth, or the SQL table name. Turn off Coerce booleans and numbers for identifiers with leading zeros.
  5. Fix any parse error before interpreting results. An unclosed tag, broken nesting, invalid character, or missing root element prevents reliable metrics and disables the conversion outputs.
  6. Compare the summary badges with Tag Schema and Node Tree. A high-count path with child tags is often a good record candidate, while a count of 1 usually points to a wrapper.
  7. Use the result tab that matches the destination. Record Fields, CSV, TSV, SQL Inserts, HTML Table, and Markdown Table are row-based; JSON, Pretty XML, Node Tree, Tag Schema, and Handoff JSON are better for structure review and integration notes.

Interpreting Results:

Read the structural badges before trusting the row output. Elements, attributes, unique tags, and Depth describe the whole parsed XML document. Records describes only the selected record path. If the document metrics look normal but Records is 0, the syntax parsed and the path selection needs attention.

Tag Schema is the quickest way to check whether the selected path makes sense. The Count, Attributes, Child tags, and Text columns show whether a branch carries enough data to become a row. Node Tree helps when the same tag name appears under different parents, because those branches can mean different things.

A preview warning is a display limit. Record preview rows caps what appears on screen from 25 to 1000 rows, and the node tree preview can also stop at the chosen depth. Downloadable row outputs are built from the converted records when records exist, so check the warning text before assuming records were lost.

The main false-confidence risk is treating a valid parse as a clean data model. Well-formed XML can still flatten badly when repeated child lists expand into many columns, namespace-prefixed names mix vocabularies, attributes carry IDs, or type coercion changes text identifiers. Check Record Fields and Tag Schema together before importing the result.

Technical Details:

XML 1.0 defines a document as a well-formed tree with exactly one root element and properly nested child elements. A parser must stop normal processing after a fatal well-formedness error because later structure cannot be trusted. That rule is why a single broken closing tag can block every conversion view.

Elements, attributes, character data, CDATA text, and namespace-qualified names all affect conversion. A namespace prefix can distinguish two names that look similar in local form, while attributes can hold identifiers that never appear as child elements. Text also needs care because machine feeds often use indentation whitespace while document-like XML may use spacing as meaningful content.

Flattening XML into rows is a projection from a tree into a table. The conversion must choose one repeated branch, map nested child values to column paths, decide whether attributes become fields, and decide whether scalar-looking text should remain strings. Full-tree outputs avoid the row projection, but row-based outputs depend heavily on those choices.

Transformation Core

The conversion path is deterministic once the XML parses and the record path policy is set.

  1. Parse the XML as one well-formed document and stop on parser errors.
  2. Walk the element tree to count elements, attributes, unique tag names, maximum depth, repeated paths, text-bearing nodes, and schema rows.
  3. Resolve the record path from auto detection, a selected suggestion, or a custom path. Auto detection favors repeated, structured elements over wrappers with little record content.
  4. Convert each matching record element into a nested value, preserving attributes and text nodes according to the active options.
  5. Flatten nested record values into shared column paths for row outputs, while preserving full-document views for JSON, formatted XML, node tree, tag schema, and handoff review.
XML conversion policies and technical effects
Policy Technical effect What to verify
Record path Every matching element becomes one structured record before flattening. The path represents the business entity, not only the deepest repeated tag.
Attributes Attribute values become fields with the chosen prefix. IDs, codes, dates, and labels in start tags are still present.
Text nodes Text content is kept as scalar values or under the configured text key when mixed with children or attributes. Mixed-content elements do not lose notes, labels, or descriptions.
Whitespace handling Leading, trailing, or repeated whitespace can be trimmed or collapsed before values are emitted. Preformatted prose, addresses, and code-like text still read correctly.
Type coercion Plain numeric text and true/false text can become JSON numbers and booleans. Identifier strings such as 00123 remain strings when leading zeros matter.
Preview limits Visible table and tree views can be capped without changing the underlying converted rows. Warnings are read as display limits, not automatic data loss.

A small record path example shows why intermediate structure matters. Given catalog > book, an element such as <book id="bk101"><title>Analytical Notes</title><price>12.50</price></book> becomes a nested record with an attribute field for @id, child fields for title and price, then a flattened row with shared headers. If type coercion is on, 12.50 can become a number; if it is off, the value stays text.

XML output views by source scope and review purpose
Output view Source scope Review purpose
JSON and Pretty XML Full parsed document. Inspecting the whole hierarchy after parsing and formatting.
Record JSON and JSON Lines Elements that match the selected record path. Passing one selected record object at a time to ingestion, logs, or queue-style workflows.
Record Fields, CSV, TSV, HTML, and Markdown Flattened records with one shared header set. Spreadsheet review, documentation tables, and simple handoffs.
SQL Inserts Flattened rows serialized as insert values with sanitized identifiers. Loading sample records into a scratch table for review or comparison.
Node Tree and Tag Schema Full document structure profile. Finding repeated paths, checking depth, and explaining unfamiliar feeds.
Handoff JSON Metrics, warnings, records, flattened records, schema rows, and generated text outputs. Sharing one review payload with another workflow or teammate.

Privacy Notes:

Pasted XML and selected XML/TXT files are read and parsed in the current browser session. Text-based outputs are generated from that local parsed data. Creating an XLSX file may load a browser-side spreadsheet exporter, but the converter does not need to upload the XML for parsing or format conversion. Use a trusted browser session for confidential feeds, credentials, or customer data.

Worked Examples:

Catalog rows from repeated books

A catalog has 800 catalog > book elements, and each book carries an id attribute plus title, author, and price children. Auto detect selects the book path, Records reads 800, and Record Fields shows columns such as @id, title, author, and price. Keeping Include attributes on preserves the book IDs.

Orders versus line items

An order export contains 50 orders > order elements and 640 orders > order > line elements. Choosing the order path makes Record Fields show 50 rows, with nested line details expanded into column paths. Choosing the line path makes Records show 640 rows, which is useful for line-item review only if each line keeps the order ID or another parent reference.

Preview limit with a large feed

A supplier feed has 12,000 item records and Record preview rows is set to 200. Records still reports 12,000, while the visible Record Fields table stops after the preview limit and shows a warning. That warning calls out the display cap; it does not mean the CSV, TSV, JSON Lines, SQL, DOCX, or XLSX exports are restricted to 200 records.

Numeric-looking identifiers

A branch export contains codes such as 0017 and 0042. With Coerce booleans and numbers on, JSON-oriented output can turn those values into numbers and remove the leading zeros. Turning the option off keeps the codes as text, which is safer when the value is an identifier rather than a quantity.

Broken nesting blocks every view

A pasted fragment such as <item><name>Ada</item> fails because name was not closed before item. The parse error should be fixed before checking Tag Schema, Node Tree, or row outputs. Closing name before item restores a well-formed branch.

FAQ:

Why did the XML parse fail?

The source must be well formed. Common causes are a missing root element, an unclosed tag, broken nesting, invalid markup in text, or an attribute value that is not quoted correctly.

Why are there no rows when the XML is valid?

The current Record path did not match a useful repeated element. Check Tag Schema for high-count paths and use Node Tree to confirm the parent branch before selecting another path.

What is the difference between JSON and Record JSON?

JSON represents the full parsed document under the root element. Record JSON contains only the elements selected by the record path, represented as an array.

When should I use JSON Lines?

JSON Lines is useful when each selected record should be one separate JSON value on its own line, such as for ingestion jobs, logs, queues, or batch review.

Does a trimmed preview mean the download is incomplete?

No. Preview trimming limits what is shown in the browser table or tree. When records exist, row exports are built from the converted records rather than only from the visible preview rows.

Why did the SQL table name change?

SQL table name is sanitized to letters, numbers, and underscores. If the name starts with a number or contains punctuation, the generated SQL Inserts output adjusts it to a safer identifier.

Does the converter send my XML to a server?

The XML text or selected file is parsed in the browser session. No server lookup is needed to build the normal conversion outputs, though your browser environment still matters for confidential data.

Glossary:

Well-formed XML
XML that follows core syntax rules, including one root element and properly nested tags.
Record path
The element path that decides which repeated XML nodes become exported records.
Attribute
A name-value pair stored inside an element start tag rather than as a child element.
Text node
Text content inside an element, separate from child elements and attributes.
Namespace prefix
A prefix on an element or attribute name that identifies the XML vocabulary for that name.
Flattened row
A nested record rewritten so child values become column paths in a table.
JSON Lines
A text format where each line is a separate valid JSON value, often one selected record per line.