How to Choose the Right Row Element in a Nested XML File

When you convert XML to CSV, one choice shapes the whole table: the row element.

Pick the right one, and your sheet is clean. One row means one clear thing. Pick the wrong one, and rows merge, split, or fill with blanks.

This guide explains the xml row element in plain words. You will see a worked example with an orders file. You will learn how to find the tag that repeats, how to spot a wrong pick, and when to trust the auto pick or change it by hand.

What is a row element?

A row element is the tag that repeats once per record.

A record is one complete item in your data. One order is a record. One product is a record. One person is a record.

In XML, data is stored in tags. A tag is a label in angle brackets, like <order>. Tags can sit inside other tags. That is what "nested" means: tags inside tags, like boxes inside boxes.

In CSV, data is stored in a table. A table has rows and columns. Each row should hold one record. Each column should hold one field of that record.

So the row element is the bridge between the two shapes. It tells the converter: "Each time you see this tag, start a new row."

If your file is a list of orders, and each order is wrapped in an <order> tag, then order is the row element. If your file is a list of books, and each book is wrapped in a <book> tag, then book is the row element.

That sounds simple. In flat files, it often is simple. In nested files, one record holds other lists inside it. An order holds a list of items. A product holds a list of colors. That is where the choice gets more interesting. You have to decide what you want one row to mean.

Before you pick, it helps to run through our step-by-step XML to CSV walk-through once, so you see where this choice sits in the full process.

A worked example: an orders file

Here is a small orders file. Read it slowly. Each order has an ID stored as an attribute, a customer, and two or more items.

An attribute is a small piece of data stored inside the opening tag itself. In <order id="A101">, the id is an attribute, and A101 is its value. Good converters keep attributes as columns, named like order@id.

<orders>
  <order id="A101">
    <customer>Ana Lee</customer>
    <total>42.00</total>
    <item>
      <name>Blue Pen</name>
      <price>12.00</price>
    </item>
    <item>
      <name>Note Pad</name>
      <price>30.00</price>
    </item>
  </order>
  <order id="A102">
    <customer>Ben Roy</customer>
    <total>15.00</total>
    <item>
      <name>Green Pen</name>
      <price>15.00</price>
    </item>
  </order>
</orders>

This file has two orders. The first order, A101, has two items. The second order, A102, has one item.

There are three items in total across the whole file.

So you have two natural ways to build a table from this file:

One row per order: 2 rows.
One row per item: 3 rows.

Both tables can be right. They just answer different questions. The row element is how you choose which table you get.

Choice A: Row element is "order" — one row per order

If you pick order as the row element, you get one row per order. The order fields become columns. The items inside each order have to share cells, because one order can have many items but only gets one row.

On XmlToCsv, repeated child values can be joined with ; in one cell. So the item names for order A101 join into one cell as Blue Pen; Note Pad.

order@id	customer	total	item/name	item/price
A101	Ana Lee	42.00	Blue Pen; Note Pad	12.00; 30.00
A102	Ben Roy	15.00	Green Pen	15.00

This table has 2 rows. It is a good order list. You can see each order at a glance. You can check totals. You can search for an order by ID.

It is less good for math on single items. The item price cell for A101 holds two prices in one cell. Most sheet tools cannot sum that cell as it is. You would have to split it first.

Pick this shape when your main unit is the order. For example: a daily order report, a list to check with a payment report, or a file you will send to a person who thinks in orders.

Choice B: Row element is "item" — one row per item

If you pick item as the row element, you get one row per item. Each item gets its own row. The order data repeats on each item row, so you still know which order each item came from.

order@id	customer	total	item/name	item/price
A101	Ana Lee	42.00	Blue Pen	12.00
A101	Ana Lee	42.00	Note Pad	30.00
A102	Ben Roy	15.00	Green Pen	15.00

This table has 3 rows. It is a good item list. Each price sits in its own cell, so sums and filters work well. You can count how many pens were sold. You can sort by item price.

But be careful with the total column. The order total, 42.00, shows on two rows for order A101. If you sum the whole total column, you will count that order twice and get a wrong grand total. This shape is right for item math, not for order math.

Pick this shape when your main unit is the item. For example: stock checks, sales counts by product, or price lists.

If you want this kind of table on a regular basis, you can also build a pivot-ready table from repeated values after you convert, or expand repeated values into one row per value during conversion. Both paths lead to one row per value. The best path is the one that fits your next step.

The key question to ask before you pick

Stop and ask this one question in plain words:

"What should one row in my sheet be?"

Say the answer out loud as "one row is one ___." One row is one order. One row is one item. One row is one product. One row is one user.

The word you put in the blank is your row element, or it is very close to it. The tag with that name is the tag you want.

This question sounds too simple, but it prevents most errors. Many wrong picks happen because the user never states what one row should be. The tool then has to guess, and any guess can miss the user's real goal. Two tables from the same file can both be valid, but only one matches the job at hand.

Write your answer at the top of your notes for the job. Then check the finished table against it. Does each row really hold one of those things? If yes, the pick was right.

How to find the repeating tag

You do not need special tools to find the row element. You need to look at the shape of the file. Here is a calm way to do it.

Step 1: Open the file and look at the top level

Open the XML file in a text tool. At the very top, you will see a root tag. The root is the one tag that wraps the whole file. In the orders example, the root is <orders>. The root is almost never the row element, because there is only one root for the whole file. Picking the root would give you one giant row.

Just inside the root, look for the tag that wraps each record. In the example, each order starts with <order> and ends with </order>. That repeating wrapper is your main candidate.

Step 2: Count tags and compare with records you expect

Count how many times the candidate tag appears. Most text tools have a find tool that shows a count. Search for <order and <order> and add the counts if needed.

Then ask: does this count match the number of records I expect? If you know the file should hold about 200 orders, and <order> appears 200 times, you have strong proof you found the right tag.

If <item> appears 540 times in the same file, that also makes sense: 200 orders can hold 540 items in total. The item count is not wrong. It is just counting a different unit. Go back to your key question: what should one row be?

Step 3: Check what sits inside the candidate tag

A good row element wraps all the fields you want in one row. Look inside one <order> block. Does it hold the customer, the total, and the items? If yes, a row built from this tag can hold all those fields.

Now look inside one <item> block. It holds a name and a price, but not the customer on its own. The customer sits outside the item, in the parent order. A good converter will still bring parent data down into item rows, as in Choice B above. But if the fields you need most do not sit inside or near the tag, think twice before picking it.

Step 4: Test with the preview

On XmlToCsv, a table preview shows the first rows before you download. Use it. Pick a candidate, look at the preview, and check the rows against your key question. Do the rows look like orders, or items, or whatever you said one row should be? Do the key columns have values? Is the row count in the right ballpark?

A two-minute preview check beats a long fix in a sheet tool later.

Signs you picked the wrong row element

Wrong picks show clear signs. Learn these four, and you will catch errors fast.

Sign 1: You get one single row

If your sheet has just one data row, you likely picked a tag that is too high up, often the root tag. All records were merged into one giant row. Cells may be very long, with many values joined in one cell.

Fix: pick the tag one level down, the tag that repeats once per record.

Sign 2: You get far too many rows

If you expected 200 rows and you got 5,000, you likely picked a tag that is too deep. You picked a small inner tag that repeats many times inside each record. That can be right if you wanted one row per inner value. But if you wanted one row per main record, it is wrong.

Fix: go back to your expected record count. Pick the tag whose count matches that count.

Sign 3: Most columns are blank

If most cells are blank, the tag you picked may not wrap the fields you need. Or records in the file have very different shapes. A few blanks are normal, because not all records hold the same fields. But a sheet that is mostly blank is a warning sign.

Fix: check one record in the source file by hand. See which tag wraps the fields you need. Then try that tag and compare previews.

Sign 4: Key fields are missing or split in odd ways

If ID columns are gone, or names are split across many columns you do not know, the row element may be wrong — or a different problem may be at work. Missing attribute columns, for example, are a separate cause of loss. To sort out which problem you have, read what goes wrong when data is lost in conversion. It walks through each cause and its fix.

The main habit is this: when the table looks wrong in a big, structural way — wrong row count, giant rows, mostly blanks — check the row element first. It controls the structure, so it is the most likely cause of a structural problem.

How auto-detect works, and when to trust it

On XmlToCsv, the row element is auto-detected. That means the tool scans the file, finds the tags that repeat, and ranks them. The tag that repeats in a way that best fits a record shape is picked first.

In plain terms, the tool asks: which tag appears many times, wraps a rich set of fields, and sits at a steady level in the tree? That tag is usually the record tag. For most common files — product feeds, order exports, user lists, book lists — the auto pick is right, and you can go straight to checking the preview.

Auto-detect helps in three ways. First, it saves time on files you have never seen. Second, it gives you a good starting point even if you later change it. Third, it handles large files well. Large files on XmlToCsv are processed with streaming, which means the file is read in small parts instead of all at once. You do not have to open a huge file by hand just to guess its shape. Plan limits for file size are: Free up to 2 MB, Starter up to 25 MB, and Pro up to 100 MB.

Trust the auto pick when the preview matches your key question. If the row count looks right, the key columns are full, and the first rows read as the unit you wanted, you are done with this choice.

When to override the pick by hand

There are good reasons to change the pick. Override it when any of these are true:

You want a different unit. The tool picked order, but your job needs one row per item. Neither pick is wrong in general, but only one fits your job. Change it.
The file holds two kinds of records. Some files mix records, like orders and returns in one file. The auto pick can only pick one main tag. You may need to convert the file twice, once for each row element, and work with two tables.
The preview shows a warning sign. One row, far too many rows, or mostly blank columns. Try the next candidate tag and compare previews side by side in your notes.
Tags have the same name at different levels. In some files, the same tag name shows up in two places with different meanings. A name alone is then not enough. You need a path.

When you override, you have two options on XmlToCsv. You can pick a different row element from the choices the tool offers. Or you can type a path by hand. A path is the chain of tags from the root down to your tag, split by slashes. For the orders file, the path to the order tag is orders/order. The path to the item tag is orders/order/item. Typing the full path tells the tool exactly which tag you mean, even if the same name appears elsewhere.

After you change the pick, always look at the preview again. Check the row count, the first row, and one row in the middle. Then download. You can convert the file with the converter on the home page right away once you are happy with the preview.

A small extra tip for repeat jobs: if you convert the same kind of file often, and you always pick the same row element and the same field mapping, paid plans can save field mapping templates. A template stores your choices so the next job starts from the right setup. Plans are Free, with 10 conversions per month and export up to 5,000 rows, Starter at $9 per month, and Pro at $19 per month. Exports are CSV and XLSX.

What about broken files?

Sometimes you open a file and the conversion stops with an error. That can be a good thing. It may mean the XML itself is broken, for example a tag was opened but never closed.

On XmlToCsv, broken XML gives a clear error with line and column numbers. You can go to that line and column, fix the flaw, and run the job again. A clear error protects you. It is much better than a silent fail that gives you a short or empty table with no hint of why.

If you get such an error, do not guess at the row element yet. Fix the file first. Row element choices only make sense once the file itself is valid and can be read in full.

FAQ

What is the difference between the root element and the row element?

The root element is the single tag that wraps the whole file. There is only one. The row element is the tag that repeats once per record, inside the root. Picking the root gives one row. Picking the row element gives one row per record.

Can one file have more than one right row element?

Yes. The orders file is a good example. order is right if you want one row per order. item is right if you want one row per item. "Right" depends on what you want one row to be. State that goal first, then pick.

How do I know how many rows to expect?

Count the row element tags in the source file, or use a count you trust from the system that sent the file, like "this export should hold 200 orders." Compare that count with the data rows in your table, not counting the header row. If you joined repeated values, the counts should match. If you expanded repeated values, the table will have more rows by design.

What if the same tag name appears in two places?

Type a path by hand instead of just a name. The path, like orders/order/item, points to one exact place in the tree. That removes the mix-up.

What if my file is very large?

Check the file size against your plan first: Free up to 2 MB, Starter up to 25 MB, Pro up to 100 MB. Large files are handled with streaming, so they are read in parts. Still, use the preview and row counts to check the result, just as you would with a small file. Large files hide errors more easily because you cannot scan them by eye.

Do attributes change which row element I should pick?

Not by themselves. Attributes are just another place data can live, inside a tag. Pick the row element based on what one row should be. Then check the preview for attribute columns, named like order@id, to make sure that data came through too.

Summary: a short checklist

Keep this list near you when you convert a nested file:

Say what one row should be: "One row is one ___."
Find the tag that repeats once per that thing.
Count that tag and compare with the records you expect.
Check the preview: row count, key columns, first rows.
Watch for warning signs: one row, far too many rows, mostly blanks.
If the pick is wrong, change it by hand or type a full path.
Check the preview again before you download.

The row element choice takes a minute to think through, and it saves far more time than it costs. Get this one choice right, and the rest of the conversion — columns, attributes, repeated values — falls into place on a table with the right shape from the start.

References

https://www.w3.org/TR/xml/ — W3C XML specification.
https://developer.mozilla.org/en-US/docs/Web/XML/Introduction — MDN XML introduction.