RTF to Text: Strip the Control Words, Keep the Words
A lot of people discover RTF the hard way. You've got a folder of .rtf files, you need the
content in a database, and since the format is technically plain ASCII you think you can just read the file
and be done. Then you look at what you loaded and it's {\rtf1\ansi\deff0{\fonttbl{\f0\froman Times
New Roman;}}{\colortbl;\red0\green0\blue0;}\viewkind4\uc1\pard\f0\fs24 Dear Sir,\par and about four
kilobytes of that before the second sentence of the letter.
RTF is text, but it's text with a markup language wrapped around it, and pulling the words out means actually parsing the control words rather than regexing hopefully at backslashes. That's what this does. Extract text from an RTF file and you get the prose in reading order and nothing else. Free, no sign-up, 50 MB limit, nothing stored on our side.
Why Naive Stripping Goes Wrong
It's tempting to write a twenty-line function that deletes anything starting with a backslash. It works on the first three files and then quietly ruins the rest. The specific ways it breaks are worth knowing even if you never write that function, because they're the same things a real parser has to handle:
- The header groups are not content. The font table, colour table, stylesheet, and revision table all sit at the top of the file in braces. Strip control words but keep the text inside those groups and your output starts with a list of typeface names.
- Braces carry meaning. Groups nest and scope formatting. Some groups —
\*\generator,\info, embedded object data — should be discarded whole, not unwrapped. - Escapes look like content.
\'92is a real character, not a control word to delete. Remove it and every apostrophe in the document vanishes mid-word. - Binary hides inside. Images live in
\pictgroups as long runs of hex digits that look exactly like ordinary text to a dumb filter. That's how you end up with 40,000 characters of0100090000in the middle of a letter. - Paragraph markers matter.
\parhas to become a line break, not nothing, or the whole document arrives as one enormous run-on paragraph.
Where RTF Turns Up in Bulk
Nobody has three RTF files. People have three thousand, because some system has been emitting them steadily since 2004. The usual suspects:
- Legal discovery and case files. Transcripts, filings, and correspondence exported from case management systems, often in one flat directory with cryptic filenames.
- Clinical documentation. Dictated notes, discharge summaries, and referral letters stored as RTF blobs in EHR tables — usually because the vendor picked it in 2003 and nothing has forced a change since.
- Government records. Chosen for the same reason the courts chose it: an open, stable spec that will still open in thirty years.
- Old email archives. Outlook's rich text mode is RTF under the skin, so it falls out of MSG email extraction constantly.
- Legacy application exports. Any CRM, helpdesk, or line-of-business tool with a rich-text field from before the web-editor era is almost certainly storing RTF in a column.
- WordPad documents. Decades of informal notes and procedures saved by people who used whatever Windows opened by default.
The common thread: these are archives you want to search, index, or ask questions across — which is exactly the job plain text is for.
Encoding Is the Part That Actually Bites
Most RTF problems in the wild are character encoding problems, not structural ones. The format was designed before Unicode was settled, and older files carry that history in them.
The header declares a code page — \ansicpg1252 for Windows Western European is the common one,
but you'll meet \ansicpg1251 for Cyrillic, \ansicpg1250 for Central European, and
\mac for files that started life on a classic Macintosh. Non-ASCII characters then appear as
hex escapes like \'92 or \'e9, whose meaning depends entirely on that
declaration. Get it wrong and é becomes a Cyrillic letter, or a curly apostrophe becomes a box.
Newer files use \uN? — a Unicode code point followed by a fallback character for readers too
old to handle it. Parsed properly you get the real character; parsed carelessly you get the fallback, which
is often a literal question mark. That's the origin of documents where every em dash and smart quote has
turned into ?.
So: before you commit a batch to a database, open two or three converted files and look specifically at apostrophes, quotation marks, dashes, and any names with accents. Those four things tell you whether the encoding was read correctly. If they're wrong, they're wrong consistently, and a find-and-replace across the batch fixes it in one go.
Text or Markdown? The Deciding Question
It comes down to whether the document has tables you care about.
RTF tables are defined explicitly with \trowd and \cellx, so they reconstruct
into pipe tables cleanly if you ask for Markdown. Flatten them to text and the values all survive but the
column each one belonged to does not — a billing table becomes a run of numbers separated by whitespace,
and no amount of prompting gets the columns back. If that's your document, use
RTF to Markdown. The format toggle
at the top of this page switches over and keeps the file you already selected.
For everything else — letters, notes, transcripts, memos, correspondence, most of what RTF is actually used
for — text is the better output. It's what full-text search indexes want, what embedding pipelines chunk by
default, what grep reads, and what a classifier expects. Markdown's asterisks and pipes would
just be characters you strip out again on the next step.
Getting Through a Large Batch
- Zip the folder. ZIP to text converts every supported file inside an archive in one pass, which is a lot better than uploading them one by one. Mind the 50 MB ceiling — RTF is uncompressed, and files with embedded images are far bigger than their word count suggests.
- Sample before you commit. Convert five files from different years first. Encoding problems cluster by era and by the tool that produced them, and a sample will show you the pattern before you process three thousand.
- Preserve filenames as metadata. Once it's flat text, the filename may be the only provenance you have left. Store it alongside each record.
- Expect boilerplate. Letterheads, footers, and standard closings repeat across every file in a corpus. They become spuriously frequent vocabulary in any frequency or topic analysis, so strip them once you spot the pattern.
- Watch for truncation. Plenty of tools emit slightly non-conformant RTF with unbalanced braces. If a converted file stops mid-sentence, the source is malformed rather than the conversion failing silently — open the original in a text editor and you'll usually see where it goes wrong.
- Check the token count. The counter under the output tells you what a document costs before you paste it anywhere, which is handy when you're deciding how much of an archive fits in one prompt.
RTF, DOCX, and Which One to Convert
If a document exists as both, take the DOCX. It carries a proper style hierarchy and richer semantics, and Word to text is the closer modern equivalent of this page.
But RTF has one real advantage for bulk text extraction, and it's not nostalgia: it's a single linear stream with no compression layer. No zip container to be corrupted, no XML parts referencing each other. When something goes wrong you can open the file in any editor and read the cause with your own eyes. Across a few thousand files of unknown provenance, that predictability is worth a surprising amount.
Frequently Asked Questions
How do I extract text from an RTF file?
Drop the .rtf into the converter above. The control words are parsed properly and you get the prose in reading order with none of the markup. Free, no sign-up, 50 MB per file, nothing stored. Download as .txt or copy it out.
Why can't I just open the RTF in a text editor?
You can, and you will see {\rtf1\ansi\deff0{\fonttbl{\f0\froman Times New Roman;}} followed by several kilobytes more before the second sentence of the letter. RTF is ASCII, but it is ASCII wrapped in a markup language. The words are in there, interleaved with font tables, colour tables and control words that have to be parsed rather than pattern-matched away.
Why does stripping backslashes myself produce broken output?
Because control words are not uniformly delimited and some carry data you must keep. A regex that deletes anything after a backslash also deletes \'e9, which is how RTF encodes an accented character — so every name with a diacritic silently loses letters. It works on the first three files and quietly ruins the rest.
Do accented and non-English characters survive?
Yes, when the file declares its encoding correctly, which most do. RTF escapes non-ASCII characters as hex sequences tied to a declared code page, and proper parsing resolves them back to real Unicode. This is the single most common failure of hand-rolled stripping, and the one that does the most damage to a names or addresses dataset.
Do tables in an RTF document convert?
Cell contents come through, but as running text rather than as a grid — plain text has no way to express a column. If the document is a report built around tables, RTF to Markdown keeps the rows and columns as pipe tables instead.
The Rest of the Toolkit
RTF is one of thirteen supported formats. File2Txt handles all of them from a single upload if you'd rather not pick a page. Nearby: PDF to text for fixed-layout documents, EPUB to text for e-books, HTML to text for saved pages, and XML to text for the other kind of legacy interchange format.
Working with code or the live web? There's the GitHub repository to text converter, a GitLab version, a local folder converter, and Web2Txt for scraping URLs. The guide to preparing documents for LLMs covers the general version of this.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.