How to Format and Pretty-Print XML Cleanly

Why Format XML?

Minified XML is fine for machines. Humans need indentation to see nesting, spot missing children, and review Git diffs. Pretty-printing changes whitespace only—parsers treat significant whitespace carefully, but for typical data documents formatting is safe.

Formatting Rules That Age Well

Consistency beats personal taste.

• Two-space indent is the common default (some Java shops use four).
• One element per line for data records; keep short empty elements on one line if readable.
• Put the XML declaration on the first line.
• Prefer UTF-8 and declare it: encoding="UTF-8".
• Do not reformat significant whitespace in mixed-content documents (HTML-like XML) without care.

Step-by-Step: Format with xmllint

The fastest CLI pretty-printer on most developer machines.

xmllint --format orders.xml > orders.pretty.xml

xmllint --format orders.xml > orders.tmp.xml \
  && mv orders.tmp.xml orders.xml

Step-by-Step: Format in Code

Useful when XML is generated in a pipeline.

import xml.etree.ElementTree as ET

tree = ET.parse("orders.xml")
ET.indent(tree, space="  ")
tree.write("orders.pretty.xml", encoding="utf-8", xml_declaration=True)

import { XMLParser, XMLBuilder } from "fast-xml-parser";
import fs from "node:fs";

const xml = fs.readFileSync("orders.xml", "utf8");
const obj = new XMLParser({ ignoreAttributes: false }).parse(xml);
const pretty = new XMLBuilder({
  ignoreAttributes: false,
  format: true,
  indentBy: "  ",
}).build(obj);
fs.writeFileSync("orders.pretty.xml", pretty);

Editors and IDE Formatters

You often do not need a separate tool.

• VS Code: XML extensions provide Format Document.
• IntelliJ / WebStorm: Reformat Code on XML files.
• Oxygen XML and similar specialist editors for large schemas.
• Vim: pipe through xmllint --format.

Pretty vs Compact

Choose based on audience—the same rule as JSON.

Attributes and Empty Elements

Small style choices improve scanability.

• Keep related attributes on one line when short: <item sku="A1" qty="2" />.
• Break long attribute lists across lines in editors that support it.
• Prefer self-closing empty elements when the schema allows them.
• Do not reorder attributes unless your team agrees—some diffs become noisy.

Formatting After CSV → XML

Generated XML from CSV is often one long line or inconsistently indented. Convert with CSV to XML, then pretty-print before sharing with a partner or committing a sample. If you need spreadsheet review instead, flatten with XML to CSV rather than staring at markup.

Real-World Examples

Where formatting habits matter.

Common Mistakes

Formatting can introduce subtle bugs if you are careless.

• Pretty-printing mixed-content XML and changing text-node whitespace.
• Stripping the XML declaration or changing encoding.
• Reordering elements in a sequence-constrained XSD document.
• Committing minified XML that makes every PR unreadable.
• Trusting a web “beautifier” with confidential partner data.

Best Practices

Keep the rules short.

• Pretty-print anything humans will read or diff.
• Use two spaces unless the project already standardized on four.
• Validate well-formedness after formatting.
• Keep partner wire files compact if size or their checker prefers it.
• Format locally with xmllint or your IDE for privacy.

Why Use Convert CSV Online?

Convert CSV Online is free, browser-based, and requires no account for everyday conversions. Generate XML from CSV, flatten XML for spreadsheet checks, and keep human review in the Online CSV Editor when markup is the wrong lens. Client-side workflows work on Windows, macOS, and Linux browsers.

Conclusion

XML formatting is about readable nesting and clean diffs—not changing meaning. Pretty-print for people, keep wire payloads as compact as partners allow, and always re-check that the document stays well-formed.