XML Summary
{{ metrics.elementCount.toLocaleString() }} elements {{ metrics.attributeCount.toLocaleString() }} attributes {{ metrics.uniqueTags.toLocaleString() }} unique tags Depth {{ metrics.maxDepth }} {{ metrics.recordCount.toLocaleString() }} records Tree preview trimmed
{{ w }}
XML Document
spaces
rows
levels
{{ header }}
{{ cell }}
No repeating record path detected. Pick a different path in Advanced.
Path: {{ metrics.recordPathDisplay || 'Auto' }}
Showing first {{ max_preview_rows.toLocaleString() }} records. Downloads include the full dataset.
Showing up to {{ max_preview_rows.toLocaleString() }} records.
{{ csvText }}
{{ tsvText }}
{{ prettyXml }}
{{ htmlTable }}
{{ markdownTable }}
{{ sqlInsertText }}
{{ treeText }}
Path Count Attributes Child tags Text?
{{ row.path }} {{ row.count.toLocaleString() }} {{ row.attributes }} {{ row.childTags }} {{ row.hasText ? 'Yes' : 'No' }}
Schema summary unavailable.
Paths are case-insensitive and ignore namespace prefixes for easier matching.
Tags: Data Format , Devops , Devtools
Export to PDF Fullscreen
:

Extensible Markup Language documents are structured text files that arrange information as nested tags and values so you can represent records, configuration, feeds, and logs in a single tree. Understanding how that structure behaves across a whole file helps you decide how to extract rows, check feeds from another team, or prepare imports for other tools.

Here you paste or drop an Extensible Markup Language document and the converter inspects every element to show counts, depth, common paths, and a quick preview of candidate records. It is especially useful when you receive unfamiliar data from another system and want a gentle schema overview before you write any code.

You provide the document text or a plain text file then choose or adjust the record path so repeating items turn into tidy rows that resemble a small spreadsheet. From there you can review nested structure in a tree view, inspect a path based schema summary, and switch between full document output and record level formats.

For example you might paste a catalog of products and immediately see that one tag repeats hundreds of times making it a natural source of rows for reporting. Remember that this converter focuses on structure and simple values rather than business meaning so always review a sample and avoid pasting confidential data when a safer sample will do.

Technical Details:

Extensible Markup Language (XML) is treated as a tree of elements, attributes, and text nodes, and the converter walks this tree to profile structure before extracting records. It counts every element node, tallies attributes, tracks unique tag names, and records the maximum depth so you can quickly gauge document size and complexity.

JavaScript Object Notation (JSON) outputs represent the full document as a nested object whose top level key is the root element name. A parallel record view selects one repeating path, converts each matching element into an object respecting attributes and child elements, and then flattens nested keys into dot paths for tabular exports.

Record detection relies on a schema profile where each unique element path stores how often it appears, how many child tags and attributes it carries, and whether it contains text. Paths that repeat and have richer child structure score higher, so auto detection typically selects the element that behaves most like a row in a table.

N r = | R | R = { e ∈ E | path ( e ) = P }
Symbol Meaning Unit/Datatype Source
E Set of all element nodes in the parsed document Set Derived from XML tree
e Single element node within the document Node Derived from XML tree
P Chosen record path made of element names String Auto detection or user input
R Subset of elements whose path equals P Set Filtered XML tree
N r Number of records produced from path P Integer Derived from R

Processing pipeline:

  1. Parse the pasted or uploaded XML text into a document tree and surface any syntax errors from the parser.
  2. Traverse every element to count nodes and attributes, detect text content, and build a schema profile keyed by element path.
  3. Score candidate paths by repetition and structural richness, then select an automatic record path unless the user chooses another.
  4. Convert each record element into a nested object, respecting options for attributes, text nodes, whitespace trimming, and type coercion.
  5. Flatten each object into a row of dot separated keys so all records share a consistent set of column headers.
  6. Render document level JSON, record arrays, JSON Lines, CSV, TSV, HTML tables, Markdown tables, SQL INSERT statements, schema summaries, and a textual tree preview.

I/O formats and encoding:

Input Accepted families Output Encoding / precision Rounding
XML source Pasted text or dropped .xml/.txt files containing well formed XML Parsed document tree and structural metrics Native text strings in the page Not applicable
Record view Elements matching the chosen record path Full document JSON and record JSON array Pretty printed JSON with configurable indentation No numeric rounding applied
Tabular exports Flattened record rows with headers CSV, TSV, HTML table, Markdown table Text values separated by comma or tab characters Numbers rendered as plain strings
Database exports Same flattened rows SQL INSERT statements with quoted literals Booleans as TRUE or FALSE, nulls as NULL Numeric text preserved as given

Validation and field limits:

Field Type Min Max Step / pattern Placeholder or notes
Indent size Number 2 8 Whole numbers only Controls JSON and XML pretty printing
Record preview rows Number 25 1000 Increments of 25 Preview trims beyond this limit
Tree depth Number 3 12 Whole numbers only Controls depth of tree preview
Attribute prefix Text 1 5 Arbitrary characters Prepended to attribute names in records
Text key Text 1 12 Arbitrary characters Key used for text node values
SQL table name Text 1 64 Sanitized to lower case identifier Defaults to dataset if left blank

Assumptions and limitations:

  • Record detection assumes that the most repeated and structurally rich path represents the intended row level.
  • Namespaces are ignored for matching, so elements sharing a local name under different prefixes are grouped together.
  • Attributes only appear in outputs when the attribute switch is enabled and use the configured attribute prefix.
  • Text extraction can trim leading and trailing spaces and collapse internal whitespace into single spaces when configured.
  • Type coercion only recognizes simple booleans and decimal numbers and leaves other values as strings.
  • Flattened column names follow discovered dot paths and array indices and may not match an existing database schema.
  • Schema and tree previews are capped at 400 rows and 600 tree lines, so very large documents show summaries rather than full listings.
  • Heads-up Auto detection may choose nested items such as line entries instead of top level records, so manual path selection is sometimes necessary.

Edge cases and error sources:

  • Malformed XML that the browser parser cannot repair will surface a parsing error instead of metrics or exports.
  • Documents without a clear repeating path can leave the Data tab empty until you choose a more suitable node manually.
  • Very deep trees may truncate the textual preview at the configured depth even though exports use the full document.
  • Extremely wide schemas exceeding 400 unique paths show only the most frequent ones in the schema table.
  • Whitespace heavy content may lose line breaks when trimming and whitespace collapse options are enabled.
  • Numeric values beyond typical double precision are stored as strings but may have been coerced earlier if they match a pattern.
  • Array flattening uses zero based indices in column names, which can surprise consumers expecting positional labels.
  • Custom record paths that do not match the document root or spelling are silently resolved to zero records with a warning.
  • HTML and Markdown exports escape structural characters but you should still treat embedded values as untrusted data.
  • SQL exports quote text values but running the statements in a database remains your responsibility, including permissions and safety checks.

Files are processed locally; nothing is uploaded. No data is transmitted or stored server side beyond the downloads you explicitly save from the page.

Spreadsheet exports rely on a small helper script loaded on demand, but all conversions and metrics are computed deterministically in the page from the XML you provide.

Step-by-Step Guide:

XML structure inspection and conversion from raw document to JSON, tables, and SQL inserts follows a short, repeatable sequence.

  1. Paste your XML text into the main editor or drop a compatible file Required.
  2. Review the summary badges to confirm element counts, attribute counts, and depth look plausible for your document.
  3. Open the Advanced panel and pick a record path suggestion or enter a custom path until the Data tab shows rows.
  4. Toggle Include attributes and Include text nodes to control which details appear in each record.
  5. Adjust trimming, whitespace collapse, and type coercion when you want cleaner values or to keep original spacing and typing.
  6. Switch between JSON, JSON Lines, CSV, TSV, HTML, Markdown, and SQL tabs, then copy or download the format you need.

For a staff directory export, choose the person level node as the record path, then copy CSV or SQL exports directly into your spreadsheet or database environment.

  • Use a smaller preview row count while exploring paths, then increase it before exporting large datasets.
  • Rely on the schema tab to confirm that important fields appear on the same record path you selected.
  • Keep the attribute prefix short so flattened column names remain readable when combined with deep paths.

Pro tip: once you find a good record path, reuse it across similar feeds to keep downstream schemas consistent.

Features:

  • Instant XML parsing with badges summarizing elements, attributes, unique tag names, depth, and record counts.
  • Automatic record path detection plus manual selection and custom path entry for irregular XML structures.
  • Configurable inclusion of attributes and text nodes, with trimming, whitespace collapsing, and type coercion options.
  • Dual JSON outputs for full documents and record arrays, plus JSON Lines for streaming style workflows.
  • Tabular exports as CSV, TSV, HTML, Markdown, and SQL INSERT statements with normalized column headers.
  • Schema profiling and tree previews that highlight repeating paths and structural hotspots for further inspection.

FAQ:

Is my data stored anywhere?

Your XML is parsed directly in the page and used only to build the previews and exports you see. Files are processed locally; nothing is uploaded, and no server side storage or logging of document content occurs.

Close the page or clear the editor to remove the content from view.
How accurate are the metrics and exports?

Element counts, attribute counts, and depth are derived directly from the parsed document tree, and exports reflect that same tree. Trimming, whitespace collapse, and type coercion options can change how text appears, so review a few records before relying on the output.

If the source XML is not well formed, results may be incomplete or unavailable.
What input formats can I use?

You can paste XML text or drop simple .xml or .txt files into the editor. Namespaces and attributes are supported, but the document must be well formed, with a single root element, for parsing to succeed.

Very large documents may still load but previews are capped for readability.
Can I run it without a network connection?

Once the page is open, parsing, schema profiling, and most exports run entirely in the page. Generating spreadsheet files may require a helper script; if it cannot load, you will see a warning and can still use CSV and other text formats.

Keep a local copy of important exports rather than relying on repeated sessions.
How do I turn XML into a table?

Choose a record path that matches the element you consider a row, then confirm that the Data tab shows sensible headers and values. From there, open the CSV or TSV tab to copy or download a table ready for spreadsheets or databases.

If the Data tab stays empty, adjust the record path in the Advanced panel.
What does a borderline result mean?

When automatic detection chooses a path that yields very few records or missing fields, it usually indicates that the document mixes several structures. In those situations treat the summary as a hint, experiment with nearby paths, and confirm that key fields appear consistently before adopting the result.

Structural validity does not guarantee that the business data itself is correct.

Troubleshooting:

  • No output and a red message usually means the XML parser encountered a syntax error; check for unclosed tags or stray text.
  • If the Data tab shows no rows, pick a different record path or use a simpler path starting at a higher level.
  • Unexpected blank columns often indicate that some records lack that field; confirm presence using the schema tab.
  • If numbers appear as text, disable type coercion or ensure the source values use plain decimal formatting.
  • When the tree preview ends with a truncation note, increase tree depth or refine the record path to inspect smaller sections.
  • If spreadsheet export fails with a warning, fall back to CSV or TSV downloads, which use only built in text handling.

Advanced Tips:

Use the schema tab to spot deeply nested paths with high counts and promote them to record paths when appropriate.

Keep the attribute prefix short, such as a single character, to avoid excessively long column names after flattening.

When preparing data for databases, align the SQL table name and column prefixes with naming conventions used in your schema migrations.

Use lower preview row counts while experimenting with paths on large documents to keep the interface responsive and readable.

Turn off whitespace collapse when text nodes carry meaningful line breaks, then reenable it once structural fields are confirmed.

For repeat use cases, note the chosen record path and option settings in project documentation to ensure reproducible conversions.

Glossary:

Extensible Markup Language (XML)
A text based format that represents structured data using nested tags, attributes, and values.
JavaScript Object Notation (JSON)
A lightweight data format representing objects, arrays, numbers, booleans, and strings.
Record path
A sequence of element names that identifies which repeated node should become one row.
Attribute prefix
Short text added before attribute names when turning them into record fields.
Text node
The character data contained inside an element, separate from tags and attributes.
Schema profile
A summary listing each element path with counts, attributes, child tags, and text presence.
Tree preview
An indented text outline of the XML structure showing tags, attributes, and text indicators.
JSON Lines
A format where each line of text contains one JSON object, suitable for streaming.