XML to Plain Text: Getting the Content Out From Between the Angle Brackets
There's a particular kind of file that turns up when you're building a text corpus: an XML export of something genuinely interesting — journal abstracts, court transcripts, a digitised archive, a decade of blog posts — where the prose you want is buried under a schema someone designed in 2006. The words are in there. They're just wrapped in three layers of tags with namespace prefixes on them.
This page pulls that content out and gives you nothing but the text. No headings, no tables, no
markup of any kind. It's what you want when the destination is an embedding model, a search index,
an NLP script, or any pipeline that treats punctuation as noise. Upload a .xml file
above — free, no sign-up, 50 MB limit, nothing stored.
What Comes Out the Other Side
Extraction is more than deleting everything between < and >. Several
things need handling properly or the output is subtly wrong:
- Entity references get decoded. XML can't contain a bare ampersand, so real
documents are full of
&,<,"and numeric forms like’for a curly apostrophe. Left undecoded, these poison word counts and make search matches fail. They come back as the characters they stand for. - CDATA sections are unwrapped.
<![CDATA[ ... ]]>is how XML smuggles content containing markup — HTML inside an RSS description, a SQL snippet, a JavaScript block. The wrapper goes, the contents stay. - Whitespace-only text nodes are dropped. Pretty-printed XML has a text node between every pair of tags containing nothing but a newline and some spaces. Keep them and your output is 60% blank lines.
- Element names disappear entirely. Unlike the Markdown version, tag names aren't kept as labels here. You get the values, not the schema.
- Comments, the XML declaration, DTDs and processing instructions go. None of them are content.
The Word-Joining Bug, and Why It Matters
Here's the failure mode that catches most naive tag-stripping, including a lot of quick regex solutions people paste from forums. Take mixed content — text and child elements interleaved in the same parent:
<p>See the <ref>appendix</ref> for details</p>
Strip tags carelessly and you can end up with "See theappendixfor details", because the tag you removed was doing the job of a word boundary. Go the other way and insert a newline at every tag and you get a sentence chopped into three fragments across three lines. Neither is usable: the first breaks tokenisation, the second breaks sentence segmentation, and both quietly corrupt anything downstream that assumes it's reading prose.
Correct handling keeps inline elements inline and only breaks lines at genuine block boundaries. If you're using something else to extract text content from an XML file, this is the first thing to test — find a paragraph with an inline tag in the middle and check that the sentence survived.
The Config File Problem
Now the honest caveat, because it will save you a confusing five minutes. XML holds data in two places: between the tags, and in attributes inside them. Text extraction, by definition, gets the first kind. Some very common XML has almost none of it.
Android manifests, .NET app.config, Ant build files, Spring bean definitions, many
SVGs — these put nearly everything in attributes. Run one through a text extractor and you get back
a handful of stray words, or an empty file, and it looks like the tool failed. It didn't; there was
no element text to find.
For those files, use the XML to Markdown converter instead, which keeps attributes attached to the elements they qualify. The format toggle at the top of this page switches over and carries your file with it, so it's one click rather than another upload. Rule of thumb: prose lives in elements, settings live in attributes. Text extraction is for the first sort.
Where Flat Text Is Clearly the Right Call
XML is the native format of an enormous amount of well-curated text, largely because institutions standardised on it before JSON existed. That legacy is where this converter earns its place:
- Building corpora. Academic abstract dumps, TEI-encoded literary texts, parliamentary and legal records, museum and library catalogues. All rich prose, all wrapped in heavy schemas. You want the prose.
- Embeddings and vector search. Embed a raw XML chunk and a real portion of the resulting vector describes the markup rather than the meaning — two documents on unrelated subjects can land near each other purely because they share a schema. Stripping the tags gives you embeddings about content.
- Chunking. Fixed-size chunkers slice raw XML mid-element and produce fragments with orphaned tags. Flat text splits on sentence and paragraph boundaries, which is what the chunker was designed for.
- Search indexing and text analysis. Term frequencies, sentiment scoring, topic modelling, entity extraction — all skewed by structural tokens repeated on every record.
- Token economy. XML's verbosity is unusual even among structured formats, since every element name is written twice. Stripping tags from a heavily nested export removes a lot of tokens that were never carrying information. The counter under the output shows you exactly how much.
When Stripping Is the Wrong Move
Models handle raw XML without difficulty — it's verbose but unambiguous, and there's a great deal of it in training data. Converting is a decision you make for a reason, not a rule.
- Writing code against the document. XPath queries, an XSLT stylesheet, a SAX or DOM parser, a schema. All of these need exact element names, namespace prefixes and the attribute/element distinction preserved. Text extraction removes precisely those. Paste a fragment of the real file.
- The hierarchy is the answer. If the question is which parent something sits under — which environment a setting belongs to, which section a clause is in — flattening destroys it. That's a Markdown job.
- Attribute-heavy documents, as above.
Frequently Asked Questions
How do I convert an XML file to text?
Drop the .xml into the converter above and the content between the tags comes back as plain prose — no angle brackets, no namespace prefixes, no attributes. Download as .txt. Free, no sign-up, 50 MB per file, nothing retained.
Does it decode entities like & and <?
Yes, and it matters more than it sounds. XML cannot contain a bare ampersand, so real-world documents are dense with &, <, " and numeric character references. A naive tag-stripping regex leaves all of those sitting literally in the output. Proper parsing resolves them back to the characters they stand for.
Why not just strip everything between angle brackets with a regex?
Because CDATA sections and attribute values both contain characters that look like markup and are not. A regex will happily eat the contents of a <![CDATA[...]]> block containing embedded HTML, and it has no way to distinguish a genuine tag from a < that appears inside quoted attribute text. Parsing gets those right; pattern matching gets them wrong quietly.
Do attribute values come through?
Element text is what you get; attributes are metadata about the element rather than content of it. That is usually correct — you want the abstract, not the schema version. Where it bites is formats that store real content in attributes, so if your output looks thin, open the source and check whether the words you wanted live inside <tag attr="...">.
Will this work on RSS feeds and sitemaps?
Yes — both are XML and both convert. An RSS feed gives you titles, descriptions and dates as readable text, which is a quick way to build a corpus from a blog archive. A sitemap gives you a list of URLs, which is more useful piped somewhere else than read as prose.
Related Tools
A note on the XML you meet indirectly: .docx and .epub files are zipped
XML underneath. You can unpack one and feed the internal markup here, but don't — it's saturated
with styling runs and revision metadata that drown the text. Use
Word to text or
EPUB to text, which know
which parts are content. For markup that's HTML rather than XML, there's
HTML to text, and for the
other big structured-data format,
JSON to text.
File2Txt accepts anything
supported if you'd rather not pick a page.
And when the XML is sitting in a repository — a POM file, a build descriptor, test fixtures — converting it on its own strips it of context. The GitHub to text converter, the GitLab converter and the local directory converter let you pull the XML and the code that reads it into one output, which is nearly always more useful. The guide to preparing files for LLMs covers the general case.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.