> Source: https://txtfetch.com/tools/odt-to-text > Plain-text twin — every page on txtfetch.com has one. https://txtfetch.com/text --- # Your .odt file, as text. No code required. Drop a real OpenDocument text file below, zipped .odt or flat .fodt. Watch it become plain text right here, in your browser. Nothing is uploaded. It's the same read txtfetch's API gives you, just local. Drop a Word, Excel, PowerPoint, or OpenDocument (.odt/.ods/.odp, zipped or flat) file below to see the actual text it extracts to. It runs entirely in your browser, and nothing is uploaded. ## whats-hard-about-odt An .odt is usually a zip archive, but not always. LibreOffice can save it as .fodt instead: a single flat XML file with no zip container at all. It carries everything a zipped .odt splits across content.xml, styles.xml, and meta.xml, in one document. Telling the two apart from a stream of bytes, and once inside, telling odt from ods from odp, never comes from the file extension. A zipped file names its type in a mimetype entry. A flat one carries the same string as an office:mimetype attribute on its root element. It's the same identity check, just read from two different places. So both variants get treated as the same document. Neither one fails with a confusing zip error. Comments and footnotes are both stored inline, right in the middle of the paragraph they annotate. That's exactly what makes them easy to get wrong. A review comment is an element sitting mid-run with the reviewer's name and note text in the flow. Read it the naive way and that text prints as if it were the document's own words. The reviewer's name gets tacked on for good measure. A footnote is its own trap: the citation mark and the footnote's actual body are two separate elements, both anchored at the point of reference. The body needs pulling out onto its own line. Leave it where it sits and it splits the host sentence in two. Then there's the tracked-changes ordering quirk that catches almost every ODF reader out. Deleting a paragraph with change tracking on doesn't remove it from the file. LibreOffice moves it into a block near the very top of , ahead of the paragraph a reader actually sees on screen. That means a struck-out sentence can show up in the extracted text BEFORE the sentence that replaced it. That reads as backwards, if you don't know the file stores it that way on purpose. Runs of repeated spaces have their own quirk too: means four spaces, not one. Skip that element and every run of spacing in the document collapses to nothing. ## what-to-do-next Got the text out and want the API call for it directly? The panel above already has it, with your file's real name. Extracting many documents, or files bigger than this browser tool's 25 MB cap? [See the full OpenDocument extraction guide (.odt, .ods, .odp) →](https://txtfetch.com/extract/odf) ## faq **Does this tool upload my .odt file anywhere?**: No. Everything happens in your browser. A zipped .odt is read with the Web Platform's own DecompressionStream API, and a flat .fodt is read directly with no unzip step at all. The file never leaves your machine; only the finished text does, and only if you choose to copy or download it. **Does it work on the flat .fodt variant, not just a zipped .odt?**: Yes. This tool sniffs the bytes for a flat file's own shape: an XML document rooted at , not a zip. It reads that the same way it would read a zipped file's content.xml. No separate upload path or setting is required. **Are comments included in the extracted text?**: No. A comment's text and the reviewer's name both live inside an element embedded in the paragraph it annotates. This tool excludes that element entirely, including the case where the comment itself would otherwise split its host paragraph in two. **What happens to footnotes?**: The footnote's body text comes out as its own line, directly below the paragraph that references it. It isn't glued into the middle of that paragraph's sentence. The small citation number itself isn't repeated in the output. **Why does a deleted sentence sometimes appear BEFORE the text that replaced it?**: Because that's genuinely where ODF stores it. Tracked-change deletions live in a block placed near the start of the document's text, ahead of the paragraph a reader actually sees. So extracted text can show the struck-out version first, then the current version further down. It's not a bug in this tool; it's a quirk of the file worth knowing about before you index one. **Does it read .ott template files the same way?**: Yes. A .ott template uses the exact same content.xml structure as a regular .odt. So it goes through the same reader here, with no special handling needed. **Is there a file size limit?**: This tool reads up to 25 MB entirely in your browser. Larger files, or a batch you want to automate, go through the same extraction via the API, which has no such limit. ## That was one file. The API does the queue. This page read your ODT on your own machine. The API reads a folder of them. [Read the quickstart →](https://txtfetch.com/docs) [Get an API key →](https://app.txtfetch.com/signup)