What XML to TXT actually does
You’ve got an XML file. You don’t care about the tags, the attributes, or the nesting. You just want the words inside. That’s the whole job here.
Paste your markup on the left and the readable text shows up on the right, tags gone. The parser reads every element, grabs the text sitting directly inside it, and stacks those pieces into clean plain text. An RSS feed, a SOAP response, an Android strings.xml, a sitemap, a sketchy export from some legacy CMS. If it parses as XML, you get its words back.
It all happens in the browser using the native DOMParser. Nothing uploads anywhere. So pasting an internal API dump or a config file with real values in it is fine.
Three switches that change the output
The defaults work for most files, but you can tune things:
- Collapse whitespace squeezes runs of spaces, tabs, and newlines down to a single space and trims the edges. XML loves to pad text with indentation, and this cleans that mess up. On by default.
- One line per element vs flatten. By default each element’s text gets its own line, which keeps a list of
<title>tags readable as a list. Flip it and everything joins into a single continuous paragraph instead. - Show element names prefixes each chunk with its tag, like
author: Andrew Hunt. Handy when the raw text alone is ambiguous and you want to know which field it came from.
Mix and match. Labels plus one-line-per-element gives you a tidy key-value rundown. Flatten plus collapse gives you a clean prose blob for word counting or feeding into something else.
When this comes in handy
Ever opened an RSS feed and just wanted the headlines without the <item> scaffolding? Or pulled a translation file and needed the actual strings, not the resource keys? This is for those moments.
A few real cases people hit:
- Grabbing readable copy out of a sitemap or feed for a quick word count
- Pulling user-facing strings from
strings.xmlto send to a translator who shouldn’t see markup - Turning a verbose SOAP envelope into something you can skim in three seconds
- Salvaging text from an old XML export when the original document is long gone
Honestly, it beats writing a one-off regex every time. Regex on XML is famously a bad idea anyway.
Things to watch out for
Broken markup won’t fail silently. If a tag isn’t closed or a & isn’t escaped, the browser’s parser flags it and you’ll see the actual parse error right there above the output, not a blank box and a shrug. Fix the markup and it converts the moment you stop typing.
Attributes don’t come through. This pulls text between tags, so <book id="42"> loses the 42. That’s by design. If you need attribute values too, an XML to JSON conversion keeps them. CDATA blocks are treated as plain text and come through fine. Comments and processing instructions get dropped, which is almost always what you want.
FAQ
Does my XML get uploaded to a server?
Nope. The whole thing parses locally with your browser’s built-in XML engine. Close the tab and it’s gone.
Why is my output blank?
Either the input is empty or it failed to parse. Check above the output box for a red parse-error message. Stray &, unclosed tags, and a missing root element are the usual suspects.
Can it handle attribute values?
No. It extracts the text content of elements only. For <item id="5">Hello</item> you get Hello, not the 5. Use an XML to JSON tool if you need attributes preserved.
What’s the difference between flatten and one line per element?
One line per element keeps each tag’s text on its own row. Flatten mashes it all into a single line. Use flatten when you want one continuous string, like for a character count.
Is there a size limit?
Practically, it’s whatever your browser can hold in memory. Files in the low megabytes convert instantly. Multi-hundred-megabyte dumps will struggle, since the parser builds the full tree before extracting.