Convert XML to Markdown Lists & Tables

Lists or tables: how the renderer decides

The decision is made per node and rests on a single test: are these repeated siblings uniformly flat? A group qualifies as a record set when it contains at least two sibling elements with the same name, each of those siblings is an element rather than bare text, and every child of every sibling is scalar — a value, not another subtree. If any sibling contains a nested element or a nested repetition, the group fails the test and the whole group is rendered as bullets instead.

That asymmetry is intentional. A table that quietly drops a nested field is data corruption wearing the costume of clean output; a bullet tree that is longer than it needed to be is merely verbose. Erring toward the lossless rendering means the only cost of a false negative is a few extra lines, while the cost of a false positive would be a silently truncated document.

Column order follows the parser rather than the source text: element children come first in document order, then attribute columns, prefixed with an at sign so an attribute named `id` cannot collide with a child element also named `id`. Columns are the union across all siblings, so a record missing an optional field gets an empty cell rather than shifting every subsequent value one column left. Cell values have their whitespace collapsed and any literal pipe escaped, which is what stops one value containing a pipe from splitting its row.

Tables are only emitted near the top of the document, where they can sit at the left margin. A pipe table indented three or four levels into a bullet list is not portable — renderers disagree about whether it is a table or a code block — so deeply nested record sets deliberately stay as bullets. If a table is what you need from a deep node, extracting that subtree and converting it on its own gives you one.

Attributes, character data and mixed content

In XML the identifier is more often an attribute than a child element, so discarding attributes would gut most real documents. They are rendered inline in parentheses immediately after the element name, which keeps a bullet tree scannable while remaining lossless: an element with two attributes and no children still produces a complete line rather than a bare label.

An element that carries only character data is collapsed onto one line as a labelled value, rather than producing a redundant child node for its own text. The same collapse applies when the element has both attributes and text, so a titled element with a language attribute renders as a single readable line with the attribute in parentheses and the text after the colon. Character data wrapped in a CDATA section is unwrapped and treated as text, which is what makes documents that embed markup or scripts inside their values convert rather than emit an object placeholder.

Mixed content — text interleaved with child elements inside the same parent — is where any tree-to-list projection is weakest. The parser separates the text from the elements, so the interleaving order is not recoverable and the text appears as its own entry alongside the child elements rather than woven between them. Documents that are genuinely narrative in this way, such as DocBook or a JATS article, are better served by an XSLT transform written against their schema, or by converting the rendered HTML output instead.

Namespaces, entities and well-formedness

Namespace prefixes are preserved verbatim as part of element names, so a prefixed element keeps its prefix in the Markdown label. This is a deliberate non-resolution: the alternative is expanding each prefix to its namespace URI, which is technically more correct and considerably less readable, and which discards the prefix your source document and your colleagues actually use to refer to the element.

Predefined entities and numeric character references are resolved during parsing, so an escaped ampersand or angle bracket becomes the literal character in the output. External and custom entity declarations from a document type definition are not resolved — this is standard, safety-relevant behaviour in browser-side parsers, because resolving external entities is the mechanism behind the classic external-entity injection class of attack. A document relying on custom entity definitions will show unresolved references, and the fix is to expand them before conversion.

Well-formedness is not optional in XML the way tag soup is tolerated in HTML. An unclosed element, a mismatched case in a closing tag, an unescaped ampersand in a value, or a stray control character will fail the parse, and the converter surfaces the parser's own message rather than guessing at a repair. That refusal is the correct behaviour: a heuristic fix-up would produce output that looks plausible while quietly reinterpreting your structure.

One coercion is worth knowing about because it is visible in the sample above: values that look numeric are parsed as numbers, so a price written as `49.00` renders as `49` and a leading-zero identifier can lose its zeros. If exact lexical form matters — a version string, a zero-padded code, a fixed-precision amount — check those fields in the output. Attribute values are not coerced and stay as written.

Local parsing, large documents and the Evernote path

Parsing runs entirely in your browser, in a worker off the main thread, so the interface stays responsive and the document is never transmitted anywhere. That matters more for XML than for most formats, because the XML sitting on a developer's disk is disproportionately likely to be a service payload with customer records in it, an integration log, a signed message or a configuration file containing endpoints and credentials. None of that should be pasted into a hosted converter, and here it cannot be, because there is no upload step to paste it into.

There is no imposed size limit. The whole document is parsed into an object tree in memory, so peak memory scales with document size rather than staying flat the way page-at-a-time PDF extraction does — a very large export is bounded by the tab's available memory rather than by a server's upload cap. In practice multi-megabyte documents convert without difficulty; multi-hundred-megabyte data dumps are a job for a streaming parser in a script, and that is the honest recommendation rather than a limitation to work around.

The same engine handles Evernote exports, which are XML with an HTML-like dialect inside them. That path is detected from the root element and behaves entirely differently: note bodies are converted as markup, checkboxes become task-list items, and tags and timestamps are lifted into frontmatter. If you are migrating a notebook rather than reading a data file, the dedicated Evernote converter is the page you want, and it uses this same local parser underneath.