RTF to TXT — decoding an old control-word grammar without guessing
Rich Text Format predates the ZIP-based containers: it is a plain grammar of control words, escapes and code-page declarations, written by legacy word processors and export tools. The decoder reads that grammar and emits paragraph text. Where a file declares something the decoder cannot map, it rejects the file instead of guessing a character set and handing you mojibake.
Character formatting, tables, images and embedded objects are ignored; only paragraph text is decoded.
Processed on your device. Files aren’t sent anywhere.
How legacy text is decoded
An RTF file is not markup; it is a stream of control words that describe characters and their formatting. Only the characters are taken.
- Plain ASCII characters are read as they are.
- Unicode escapes carry characters outside the file's declared code page, which is the fallback that lets accented and non-Latin text survive.
- Escaped braces are read as literal brace characters rather than as group boundaries.
- Paragraph marks become line breaks, so paragraph order is preserved.
- Formatting control words — bold, italic, font size, colour — are ignored; the characters they modify stay.
- Tables, images and embedded objects are not decoded into the text.
Code pages that are supported and code pages that reject
Legacy files declare a code page for the single-byte characters they use. This decoder handles a defined range and refuses anything outside it.
| Declaration in the file | Response | Why |
|---|---|---|
| Windows-1250 through Windows-1258 | decoded | Central European and Baltic single-byte sets are mapped |
| Unicode escapes for characters outside the code page | decoded | the escape carries the character directly |
| Escaped braces | kept as literal characters | the escape is not a group boundary |
| A code page outside the supported range | rejected | guessing a character set would produce wrong characters |
| A malformed control stream | rejected | the grammar cannot be parsed into text |
Escaped braces and control words
Braces delimit groups in RTF, so a document that needs a literal brace escapes it. The decoder treats those escapes as characters, which is why source code or pseudocode stored in an old RTF file survives with its braces intact.
Unknown control words are not treated as text. A file full of vendor-specific control words still yields the paragraph text, but the formatting those words described is lost — only paragraph text is decoded.
Questions about legacy decoding
Does RTF to TXT support every old code page?
What happens to bold, tables and images?
Will literal braces be lost?
Is the file sent to a server?
Why rejection beats a guess
A wrong code-page guess produces plausible-looking garbage: accented letters replaced by unrelated symbols, silently. A rejection tells you the file needs a different route.
This is not universal legacy support. Files declaring code pages outside the supported range are refused; they are not decoded by a fallback heuristic.
- Convert the .rtf and read the result; a rejection is a named error, not an empty file.
- Check the accented characters you expect — Central European letters are the reason Windows-1250 through 1258 are mapped.
- Check literal braces if the file holds code or pseudocode.
- Look for table content that arrived as separate lines or not at all, since tables are ignored.
- For a rejected file, re-save the source in a modern format and convert that instead.
- Compare the character count with the 400000-character output cap.
What plain text cannot recover
RTF stores formatting as instructions, and a text-only output cannot rebuild them.
- Character spacing and tab stops become ordinary spaces.
- Colour, font face and size are gone; emphasis is not preserved in plain text.
- Tables flatten into lines, so column alignment is lost.
- Footnote text is not part of the body extraction, so notes must be checked separately.
- A file that declares an unsupported code page is rejected rather than guessed at.