Your API returned one giant line of XML. Here is how to read it

You call an endpoint, you get a response, and it is one enormous line of XML. No line breaks. No indentation. Just a wall of angle brackets that your eyes slide straight off.

You could paste it into your editor and hope the formatter plugin is installed. You could squint at it in the terminal. Or you could format it in about two seconds, in the browser, without uploading it anywhere.

Why XML arrives as one line

Minified XML is not broken. APIs and export tools strip whitespace on purpose, because whitespace costs bytes and machines do not care about readability. The document is perfectly valid. It is just unreadable to a human.

The fix is mechanical: re-indent every element by its nesting depth. An opening tag pushes the next line one level deeper. A closing tag pulls it back. Text content stays on its own line. That is the whole trick, and any tool that does it well is worth keeping bookmarked.

Format it in the browser, privately

The fastest route is a formatter that runs entirely in your browser. Paste the blob, pick an indent (two spaces is the usual default, four if your team prefers it), and you get a readable document back. No upload means the XML never leaves your machine, which matters when the payload contains internal endpoints, customer records, or production config.

I built one for exactly this job: a free XML formatter and validator that pretty-prints, minifies, validates, and converts XML to JSON, all client-side. It flags malformed XML with the exact line and column of the problem instead of a vague "parse error", and it refuses DOCTYPE declarations and external entities, so pasting untrusted XML cannot trigger an XXE-style surprise. Try it here: https://www.theutilityhub.online/tools/xml-formatter

The errors you will actually see

Most malformed XML is one of three mistakes:

1. Mismatched tags. <user><name>Alex</user></name> closes the tags in the wrong order. XML is strict about nesting, unlike HTML, which forgives it.
2. Unclosed tags. One <item> never gets its </item>, usually after a copy-paste.
3. A second root element. XML allows exactly one root. Two top-level elements is not a document, it is two documents glued together.

A good validator points at the line and column. A bad one just says "invalid". When you are debugging a 200KB response, that difference is the whole job.

Minify, and XML to JSON

Formatting is only half the tool. Minify does the reverse: it strips the whitespace back out when you need the smallest possible payload to paste into a test or a config field. And XML to JSON conversion is handy when the rest of your pipeline speaks JSON and you want the data, not the markup.

One habit makes all of this painless: never debug raw XML. Format first, read second. The bug is almost always visible the moment the nesting is correct.