How to Translate an RTF File: What Survives and What Breaks

To translate an RTF file, upload the whole .rtf file to a translator that reads RTF, then check the result. BookTranslator accepts RTF. It reads the text one paragraph at a time, translates it, and gives you a new RTF file and a bilingual RTF file. Pasting the text into a chat window or a web translator also works for a page or two, but you lose the file and have to rebuild it.

There is one thing to know before you upload. The translated file keeps your words and your paragraphs, but not your formatting. Bold, headings, fonts, tables, links, and images do not come back. So the right route depends on what is in your file and which app saved it. A plain manuscript saved from Word is the easy case. A file saved by TextEdit on a Mac needs one extra step first, or every paragraph runs together.

We made three test files and wrote a free checker that shows what is in an RTF file before you upload it and what changed after. We ran the test files through a local copy of the RTF reading and writing code BookTranslator uses, with a marker in place of a model, so you can see exactly which text each test file sends for translation and how the file comes back.

Quick Answer: What Happens to Each Part of the File

The rest of this guide shows where each row comes from and what to do about it.

Step 1: Check Which Kind of RTF You Have

RTF is a text format with formatting codes in it. Open the file in a plain text editor, or run head -c 120 yourfile.rtf in a terminal, and look at the first line.

• If it has \cocoartf in it, the file was saved by Apple's text system: TextEdit, or another Mac app that uses it.
• If it has \rtf1\ansi and no \cocoartf, it is most likely from Word, LibreOffice, WordPad, or a writing app's export.

The difference matters because the two kinds end a paragraph in different ways. Word and most other word processors write the code \par at the end of each paragraph. Apple's text system writes a single backslash at the end of the line instead. Both are valid RTF: Microsoft's original 1989 RTF specification (mirrored copy) says a backslash followed by a line break is treated the same as \par, and Apple's own reader shows our TextEdit test file as separate paragraphs. BookTranslator's RTF reader splits paragraphs on \par only. We checked this in its code on November 3, 2026 and in the test below.

The checker tells you which kind you have, and what else is in the file. It needs Python 3 and nothing else:

python3 check_rtf.py sample-word-style.rtf

On our Word-style test file it printed:

== sample-word-style.rtf
  par_breaks: 7
  table_cells: 4
  table_rows: 2
  hyperlinks: 1
  fields: 1
  bold_on: 2
  italic_on: 1
  page_breaks: 1
  fonts: 2
  footnotes: 1
  headers: 1
  images: 1
  visible_paragraphs: 7
  WARN 4 table cells: check that cell boundaries survive.
  WARN 1 footnotes: check where this text ends up in the output.
  WARN 1 headers: check where this text ends up in the output.
  WARN 1 hyperlinks: the link text may survive without the URL.
  WARN 1 images: keep the original for the artwork.

On the TextEdit file, the first warning was this one:

  WARN Paragraphs end with a backslash + line break (TextEdit/Cocoa style), not \par. Tools that only split on \par will see one long paragraph.

If the checker prints no warnings, your paragraphs, numbers, and text should come through. Bold, headings, and lists do not trigger a warning, but they are still removed on the RTF route, so check Step 2 if you need them.

What Came Back From Our Test Files

We made three small files. All of them, and everything that came back, are in the test file folder.

• sample-word-style.rtf is hand-written in the style Word uses for RTF: \par breaks, a page header, a footnote, a link, a two-by-two table, a small image, a page break, café written as a code page character, and 日本 written as Unicode codes.
• sample-textedit.rtf was made on a Mac with textutil -convert rtf, which uses the same text system as TextEdit. It has a heading, bold and italic words, a link, a bulleted list, a table, and a line with {braces} and backslashes in it.
• sample-long-numbers.rtf has a 20-digit order reference, a 40-character commit hash, and a phone number.

We copied the RTF reading and writing functions from BookTranslator's backend code on November 3, 2026 and ran them on each file. No model was used. Every paragraph that would be sent for translation was replaced with [ZH] plus the original text. That shows exactly what a model would receive and how the file is rebuilt, without the noise of a real translation.

The Word-style file: six clean paragraphs, with three surprises

The file came back as six translated paragraphs, in this order:

[ZH] Harbor Notes - Draft 2
[ZH] Chapter 3: The Harbor
[ZH] The ferry left at 6:40, an hour before the café opened. Timetable from the 1998 edition.
[ZH] Read the harbor map before you go.
[ZH] StopTimeNorth pier7:05
[ZH] Chapter 4: 日本 (Nihon)

Most of this is what you want. Each paragraph was sent once, in order, and café and 日本 survived the trip from RTF codes to text and back. The three surprises:

1. The page header became the first paragraph. "Harbor Notes - Draft 2" was a header that printed at the top of each page. In the translated file it is body text.
2. The footnote moved into the sentence. "Timetable from the 1998 edition." was a footnote on "opened". It now follows the sentence as if it were part of it, and the footnote number is gone. A model translating that paragraph sees one run-on text, and you have to find and move the footnote back by hand.
3. The table cells ran together. The four cells "Stop", "Time", "North pier", and "7:05" became the single string StopTimeNorth pier7:05. A model may split it in the wrong place, or translate "StopTime" as one word.

The translated file has no header, no footnote, no table, no link address, no image, and no bold. The checker's compare mode in Step 4 lists all of that.

The TextEdit file: one paragraph

The TextEdit file has eight visible paragraphs. All of them were sent for translation as one paragraph:

Chapter 3: The HarborThe ferry left at 6:40, an hour before the market opened.Read the harbor map before you go.	•	Bring cash	•	Keep your ticketStopTimeNorth pier7:05Ana said: "We'll wait {here}" and C:\Users\ana\notes stayed open.

There is no space where each paragraph ended: "HarborThe", "opened.Read". The translated file is one paragraph too. Our test file is short. In a real book saved by TextEdit, the whole file becomes one paragraph. Before translation, BookTranslator cuts very long paragraphs into pieces of about 6,000 characters (about 2,000 for Chinese, Japanese, or Korean), at sentence ends where it can find them. Those cuts still fall at sentence ends inside paragraphs, but never at the missing paragraph breaks, because "opened.Read" does not look like a sentence end. Where each paragraph is a single sentence, such as dialogue lines or list items, cuts can fall at commas or spaces. The model never sees where the paragraphs were, and you get back one wall of text.

The braces and backslashes in the last sentence did survive. They were escaped correctly on the way out, so the file still opens.

The long numbers: deleted before translation

The third file came back like this:

[ZH] Your order reference is  and must be quoted in full.
[ZH] The fix landed in commit  last week.
[ZH] Call +44 20 7946 0958 before 5 pm.

The order reference and the commit hash are gone, with a double space where each one was. The reader removes any run of 20 or more characters made only of the digits 0–9 and the letters a–f, because that is how embedded image data looks in RTF. A long number in your text looks the same to it. The phone number survived because its digit groups are short.

This mostly matters for contracts, invoices, technical notes, and records with long reference numbers. The checker lists every such string in your source file and tells you if one is missing after translation.

Step 2: Choose the Right Route for Your File

Use the checker's output to pick one:

To convert a TextEdit file on a Mac, open Terminal and run one of these:

textutil -convert docx notes.rtf
textutil -convert txt notes.rtf

The first writes notes.docx next to the original. When we converted our TextEdit test file this way, the DOCX had a separate paragraph for each line and kept the bold and italic words. It did not keep the table, which became separate paragraphs, or the link. If you need those, open the file in Word or LibreOffice and save it as DOCX from there, then check the table before you upload. The second command writes a plain text file. Use it when you only need the words; our plain text translation guide covers what to check in a TXT file.

For a Word document where tables, styles, and headers matter, see our guide to translating a Word document while keeping the format. BookTranslator's FAQ on its document translator page gives the same advice for old Word .doc files: it translates their text and returns an RTF file, and recommends saving them as DOCX first when the images, tables, or layout need to stay.

Step 3: Translate the Whole File

Upload the file, choose the target language, and check the price before you pay. BookTranslator translates the paragraphs in order. For a long file with recurring names and terms, turn on the Auto glossary option before you pay, so they are translated the same way throughout.

You get two files:

• The translated file: each paragraph in the target language.
• The bilingual file: each original paragraph followed by its translation. This is the faster file for review, because you can read the two side by side and spot a paragraph that was skipped or misread. In the bilingual file for our TextEdit test, the whole document appears once in English and then once with the marker, which is another way to see the one-paragraph problem.

Both files are written as plain 12-point Times New Roman paragraphs. Right-to-left target languages, such as Arabic and Hebrew, are marked as right-to-left paragraphs. Open the files in Word, LibreOffice, or TextEdit to read and format them.

Step 4: Check the Translated File

Run the checker with the source file and the translation:

python3 check_rtf.py sample-word-style.rtf sample-word-style-translated.rtf

For our Word-style file, the compare section printed:

== compare
  CHANGED table_cells: 4 -> 0
  CHANGED footnotes: 1 -> 0
  CHANGED headers: 1 -> 0
  CHANGED hyperlinks: 1 -> 0
  CHANGED images: 1 -> 0
  CHANGED bold_on: 2 -> 0
  CHANGED italic_on: 1 -> 0
  CHANGED page_breaks: 1 -> 0
  CHANGED visible_paragraphs: 7 -> 6

Each line is a job for your review. Here, the paragraph count went from seven to six because the table rows became one paragraph. For the long-numbers file it printed two MISSING lines, one for each number that was deleted. For the TextEdit file, visible_paragraphs: 8 -> 1 is the sign to go back to Step 2.

The checker counts the structure. It cannot tell you if the translation is good. Read the bilingual file, at least for the opening pages and any passage with names, numbers, or dialogue.

Common Problems

My translated RTF is one long paragraph. Your source file most likely came from TextEdit or another Mac app. Run the checker on the original. If it warns about backslash line breaks, convert the file to DOCX or TXT and translate that instead.

Some words are stuck together, like "StopTime". Those were table cells. RTF tables lose their cell boundaries on this route. Translate a DOCX copy of the file if the table matters.

A sentence ends with text that does not belong to it. That is probably a footnote. Find it in the original, then move its translation back into a footnote in Word.

A number is missing from the translation. If it was 20 or more characters of 0–9 and a–f, it was removed before translation. Copy it back from the original. The checker's MISSING lines list every one.

The formatting is gone. That is expected on the RTF route: the file is rebuilt with plain paragraphs. If you need the formatting, translate a DOCX copy, or apply the styles again after translation. Our comparison of DOCX translation tools covers which tools keep Word formatting and how well.

Can I get the result as DOCX instead? Not from an RTF upload; RTF goes in, RTF comes out. Convert the original to DOCX before you upload, and the result comes back as DOCX.