Free Online XML Viewer
Drop an XML file below, or paste the markup, and read it as a table: the repeating element becomes rows, its children and attributes become columns, and the grid sorts, filters and exports. An element tree with copyable paths is one click away. Parsed in your own tab.
XML is a table wearing a costume
Most XML that turns up in working life is not a document in any interesting sense. It is a table: a vendor's product feed, an invoice batch, a payroll export, a bank statement in one of the many XML dialects banks favour, an RSS feed, a sitemap. There is a root element, there are a few hundred or a few thousand identical children under it, and each child holds the same handful of fields. That is a spreadsheet written in angle brackets.
The trouble is that reading it as a spreadsheet is oddly hard. Open the file in a browser and you get a collapsible tree, which is fine for twelve records and useless for twelve hundred. Open it in a text editor and you are counting indentation. The advice you will find is to write an XSLT, or a small script, or to import it into Excel through a wizard that asks you to pick a schema you do not have.
This page skips all of that. It reads the markup, finds the element that repeats, makes each repetition a row, and makes the fields inside them columns. Attributes count as fields too, because whether the author wrote <price currency="USD">29.00</price> or <price>29.00</price><currency>USD</currency> is a decision you should not have to care about while reading their data.
The tree is still there when you want it. The XML tree tab shows the document the way it is actually built, with attributes inline on each element and the path to any node copyable in one click, and it renders lazily so a large feed does not put ten thousand nodes into the page at once.
What is on the page
The repeating element becomes rows
No schema, no XSLT, no wizard. The element that repeats is found by reading the document, and each repetition is a row of the table.
Attributes are columns too
A field written as an attribute gets a column beside the fields written as child elements, so the author's markup style does not decide what you can see.
A tree with copyable paths
The XML tree tab shows the document as it is built, with attributes inline. Hover any node and copy its path, indexed where siblings share a name.
Sort and filter
Click a header to sort by that field, numbers as numbers and dates as dates. Filter as you type across every column, or narrow to one with category:tools.
Type and role badges
Every column is badged with the type its values support. XML has no types of its own, so this is often the first time anyone has looked at whether a feed's price field is really numeric.
Column statistics
The sigma in a header gives blanks, distinct count, min, max, mean, median, sum and the most common values, which is how you find the six products in a feed of four thousand that have no price.
Freeze and select
Pin the first columns so the SKU stays visible across a wide record, and drag to select any rectangle of cells.
Copy or export
Copy as TSV, CSV, Markdown or JSON for a selection; Download CSV or .xlsx for the current view. A vendor feed becomes a spreadsheet in two clicks.
Paste, do not save
The Paste tab takes markup straight from a response body, so you never have to write a SOAP envelope you are debugging to disk. Nothing is transmitted either way.
A worked example
Take a small product feed:
<?xml version="1.0" encoding="UTF-8"?>
<catalog updated="2025-09-01">
<product sku="SKU-0042" category="Assemblies">
<name>Widget assembly</name>
<price currency="USD">620.00</price>
<stock>41</stock>
</product>
<product sku="SKU-0117" category="Drivetrain">
<name>Sprocket set</name>
<price currency="USD">106.25</price>
<stock>0</stock>
</product>
</catalog>
product is the element that repeats, so you get two rows. The columns are sku and category from the attributes, name, price and stock from the child elements, and currency from the attribute on price. Nothing in the document is thrown away because of where the author decided to put it.
The badges tell you something immediately: price reads num / currency and stock reads int / count, which means both parsed as numbers. If price had come back text, some row in the feed has a value like POA or 1,299.00 in it, and every downstream numeric comparison is about to behave strangely.
Click the sigma on stock: two values, none blank, min 0, max 41. Sort by stock ascending and the out-of-stock row comes to the top. Type category:Drivetrain in the filter and the counter reads 1 of 2 rows.
Switch to the XML tree tab and the document is there as written: catalog with its updated attribute inline, two product children, each expandable. Hovering the second product's price and clicking copy path puts /catalog/product[2]/price on the clipboard, indexed because there is more than one sibling with that name.
Where XML gets awkward
- Records with different fields. Feeds are ragged: some products carry a
discountelement and some do not. The table takes the union of the fields and leaves the gaps blank rather than shifting values into the wrong columns. - Repeated children inside a record. A product with three
tagelements cannot become one flat row without losing something. The tree is where that structure stays visible. - Mixed content. An element holding both text and child elements is common in document-shaped XML and rare in data-shaped XML. The table handles the data-shaped case well and the tree handles the rest.
- Namespaces. Prefixed names are shown as written, so
ns:priceappears under that name. Prefixes are not resolved to URIs and you cannot query by namespace here. - Documents that will not parse. An unescaped ampersand, an unclosed tag or two roots will stop the parse. You get the specific complaint rather than a blank page, and the formatter tools are the better place to repair it.
Frequently Asked Questions
How do I view an XML file as a table?
Drop the file on the box at the top of this page, or paste the markup into the Paste tab. The repeating element is found automatically and each one becomes a row, with its child elements and attributes as columns. Sorting, filtering, per-column statistics and CSV export all work on the result, and nothing is uploaded.
How does the viewer decide what a row is?
By looking for the repeating element. An XML document that holds data almost always has one: a products document has many product elements under a products root, an RSS feed has many item elements. That repeated element becomes the row, and its children and attributes become the columns. If the document has no repetition, you get one row and the tree view is the more useful of the two.
Are attributes included, or only child elements?
Both. XML lets the same fact be written either as an attribute or as a child element, and which one an author chose is not something you should have to care about when reading the data. Attributes become columns alongside element columns, and the element tree shows attributes inline on their element so you can see how the document is actually built.
What is the XML tree tab for?
Structure rather than counting. It shows the document as a collapsible tree with attributes inline and the path to any node copyable in one click, which is what you want when the question is what shape is this or where does that value live. The table is the right view for how many and how much. Nodes render lazily, so a big document does not become a stalled tab.
Does it handle namespaces?
Yes, in the sense that a namespaced document parses and displays. Prefixed element names appear as written, so an element called ns:price shows up under that name rather than being silently rewritten. The viewer does not resolve prefixes to their URIs or let you query by namespace; for that you want a dedicated XPath tool.
What happens with malformed XML?
You get the parser's complaint reduced to the line that says what broke, rather than the page-length apology browsers normally produce. An unclosed tag, a stray ampersand that should have been escaped, or two root elements are all reported as the specific problem they are. There is nothing to fix them with here; the XML formatter is the better place for that.
Can I export the table as CSV or Excel?
Yes. Download CSV and .xlsx write the current view, so filtering and sorting first gives you exactly the rows you want. For part of the table, select a range and use Copy as for TSV, CSV, a Markdown table or JSON. This is the quickest route from a vendor's XML feed to a spreadsheet somebody can actually work with.
Is the file uploaded?
No. There is no upload endpoint on this page. The markup is parsed by your browser's own XML parser in your tab, nothing is transmitted, and nothing is stored between visits. That matters for the kind of XML that tends to need viewing: invoices, payroll exports, health records and bank statements.
Related tools and guides
Read the feed as what it is
A table for the data, a tree for the structure, no XSLT and no upload.
Back to the viewer