Two different error messages come out of a failed OmegaT export, and they mean opposite things. One says your tags are broken. The other says your file is perfectly healthy and Word simply will not let you near it. Fix the first the way you would fix the second and you lose an evening, which is the distinction that catches most people out.
So let me cover both, along with what actually changed in the new version.
First, the version you should be on
OmegaT 6.1.0 shipped on 2 August 2026 carrying 65 enhancements, 100 bug fixes, and 5 localisation updates compared with 6.0. As I write this, omegat.org lists 6.1.1 as the current download, so that is the one to grab.
It is a real release, not a cosmetic one. But almost nobody notices the new spell checker on day one. What they notice is a Word file that comes out wrong.
OmegaT never opens your Word document
Here is the thing most tutorials skip, and it is the single idea that makes everything else make sense.
A .docx is a ZIP archive stuffed with XML. Nothing more. OmegaT unzips it, pulls the translatable text out of that XML, wraps every piece of formatting in a little placeholder marker (those are the tags), and hands you the plain text to work with. When you finish, it stitches the XML back together and re-zips the whole thing. Microsoft Word is never involved at any point in that process.
The rule everything else follows
The tags in your segments are not clutter. They are your formatting. Move one, delete one, or split a pair down the middle, and the XML you hand back is malformed.
Delete the tags because they look distracting and the export will still run without a single warning. The file just will not be usable. That one habit sits behind most of the "OmegaT broke my Word file" complaints, and it has nothing to do with which version you are running.
Once that clicks, the rest of this article is procedure.
What changed in 6.1
Two of these affect whether the program will even start, so skim them before you upgrade.
It needs a much newer Java
Version 6.0 ran on Java 11. The 6.1 line wants Java 21 or later, and the bundled installers now ship with Java 25 inside them.
If you are the sort of person who downloads the smaller "without JRE" package, check your Java version first. Unless you have a specific reason, take the "with JRE" package. It is bigger, it works, and you never think about it again. I gave up managing my own runtime a long time ago.
Native Apple Silicon and ARM Linux builds
M-series Mac users finally get a proper arm64 build with a matching runtime. Same story for Linux on aarch64. Before this, those setups either ran through a translation layer or misbehaved in ways that were hard to diagnose.
Linux users also get real .deb and .rpm packages now, so installation goes through the normal package manager instead of unpacking a folder somewhere and hoping.
The interface follows your system theme
OmegaT now picks up your operating system's light or dark setting automatically on Windows and macOS. It sounds trivial. If you regularly work past midnight, it is not.
Spell checking got rebuilt, LanguageTool went to 6.5
Spell checking is now a plugin-style module with support for Morfologik dictionaries and the ones bundled with LanguageTool. LanguageTool itself moved up to 6.5.
Worth knowing: an early 6.1 build had a reported bug where automatic spell checking silently stopped working. It is fixed and listed in the release notes. That is a good reason to run 6.1.1 rather than a weekly build you downloaded months ago and forgot about.
The quieter stuff
SRX segmentation support arrived. Log files now carry a date and time in the filename instead of overwriting each other, which matters the moment you need to reconstruct what happened during a team sync. Alternative translations get their own highlight colour. Team projects can be pulled with a shallow history, which is dramatically faster on a repository with years of commits behind it.
Two fixes matter directly for anyone producing deliverables: OmegaT was mishandling line breaks on Windows, and it was generating XLIFF that some other CAT tools flatly refused to read. Both are patched.
Version 6.2 is in development with another 17 enhancements queued, including a "whole words only" search option. It is not out yet, so do not go hunting.
The five things that actually break Word exports
Roughly in the order they turn up.
You edited, moved, or deleted a tag
What you will see
Word warns about unreadable content, or the file opens with the formatting scrambled. A paragraph is suddenly bold. A heading turned into body text.
Why it happens
Tags come in pairs and singletons. Split a pair, reorder it, or delete half of it, and you produce overlapping XML. The OmegaT manual is blunt about this: overlapping tags corrupt formatting and can stop the file opening at all.
How I handle it
Press Ctrl+T before every single export. It scans the whole file and lists any segment with a suspect tag. Then run Check Issues as well. I treat both as non-negotiable, the same way I would never send a translation without a spellcheck. Thirty seconds there saves hours of picking through a broken file in Word.
Your source document is a tag soup
What you will see
A perfectly ordinary sentence arrives in the editor chopped into six fragments with a dozen tags scattered around normal words.
Why it happens
Word stores invisible metadata on each text run, including spell-check state, revision save IDs, and language markers. A sentence that has been retyped, pasted, or spell-corrected gets internally split into many runs. OmegaT shows every one of them, because every one of them is genuine formatting data. This is not an OmegaT flaw. Every CAT tool chokes on the same documents. It is a Word artifact.
How I handle it, in order
- Clean the source before starting. CodeZapper is a free Word macro set built for exactly this. It strips the junk runs and leaves the real formatting alone. It is the first thing I run on any file that arrives from a marketing department.
- If that does not help, open the .docx in LibreOffice, save it as .odt, and translate the ODT instead. Round-tripping often collapses the noise. It does not always work, but it costs nothing to try.
- Failing both, turn on Aggregate tags in Preferences so consecutive tags merge into one block. Then you are moving one marker instead of six.
Do all of this before you translate a single segment. Cleaning afterwards means re-segmenting, and you lose your alignment with the memory.
Text placed before the first tag vanishes
What you will see
Your translation is right there in the segment, the tags validate cleanly, and yet part of the sentence is simply missing from the exported file.
Why it happens
This is documented behaviour tied to the Remove leading and trailing tags filter option. When it is switched off, OmegaT keeps leading tags where they are, and anything typed before that opening tag can get dropped when the target is rebuilt.
How I handle it
I never start a translation before the opening tag. Text goes after it, always. If you would rather not have to remember that, enable Remove leading and trailing tags under Options › File Filters, or per project under Project › Properties › File Filters. It shields you from the whole problem.
"Remove Tags" left you with a blank document
What you will see
The export runs, no errors, and the Word file is empty or nearly so.
Why it happens
The Remove Tags option hides tags from view, but the formatting data still governs how the target gets reassembled. With nothing to anchor the text to, OmegaT cannot put it back where it belongs.
How I handle it
I do not use Remove Tags on Word files. Ever. It exists for cases where you genuinely do not need the original layout back. If you have already done it, switch it off, reload the project, and export again. Nothing is lost. Your translations are in the memory, and only the target file needs regenerating.
Arabic, Hebrew, and other right-to-left targets
What you will see
Layout drifting in the target file, or chunks of text arriving bold when the source was not.
Why it happens
With a right-to-left target language, OmegaT adds an RTL marker to each text run's formatting block. Runs that came out of Word without a formatting block get handled inconsistently. It is a tracked limitation of the Word filter, reproducible in both Arabic and Hebrew but not in left-to-right languages.
How I handle it
There is no switch that solves this one, so I stop pretending there is. Clean the source aggressively to cut the run count down, then budget a formatting pass in Word after export. If you work into RTL languages regularly, put that DTP time in your quote. It is not free labour.
When Word says it "experienced an error trying to open the file"
This deserves its own section, because it looks exactly like the tag problem and usually is not.
The dialog reads
Word experienced an error trying to open the file. Try these suggestions.
- Check the file permissions for the document or drive.
- Make sure there is sufficient free memory and disk space.
- Open the file with the Text Recovery converter.
Read that carefully. Word never claims the content is unreadable. It is saying it could not reach the file, or could not make sense of it once it did. Two different problems, two opposite fixes. It is easy to chase this down the wrong path, re-checking tags on a file that turns out to be perfectly healthy.
Step one: work out which problem you have
Open the same file in LibreOffice Writer. That is the whole test, and it takes about ten seconds.
- It opens in LibreOffice: the file is valid. Word is refusing it, not failing on it. Skip to the next section.
- LibreOffice chokes too: the file really is malformed. Go back to the tag section above.
While you are there, two quick extras. Check the file size, because a 0 KB or suspiciously tiny target means OmegaT never finished writing it. And try renaming a copy from .docx to .zip and opening that. If the archive will not open, the file structure itself is broken.
Word is blocking the file, which is the usual answer
Word ships with a Trust Center that quarantines documents it thinks came from somewhere risky: the internet, a network share, an email attachment, a cloud sync folder. Normally you get the friendly yellow Protected View bar. Sometimes you get this error instead.
There is a useful clue hiding in the dialog itself. If the filename in the parentheses shows %20 where the spaces should be, something like Annual%20Report%20Draft.docx, then Word is being handed a URL-encoded path rather than a plain local one. That happens when a file gets opened through a link, a browser download, or a cloud storage connector instead of straight off your disk. Treat it as a strong hint that the problem is location and trust rather than translation, then confirm it with the LibreOffice test.
Fixes, cheapest first:
- Unblock the file. Right-click it, choose Properties, and on the General tab tick Unblock at the bottom. If that checkbox is not there, the file is not blocked and you can move on.
- Move it somewhere boring. Drag the target file out of Dropbox, OneDrive, Google Drive, or Downloads and into your Documents folder. Cloud folders trigger this constantly. Worse, if the file is still syncing or stored online-only as a placeholder, Word may be opening a stub with nothing inside it.
- Simplify the filename. Rename it to something short with no spaces, apostrophes, or accented characters. Something like annual-report-en-id.docx. Spaces are precisely what %20 is encoding.
- Add a trusted location. In Word, go to File › Options › Trust Center › Trust Center Settings › Trusted Locations › Add new location and point it at your OmegaT /target/ folder. Tick "Subfolders of this location are also trusted." This is the fix that actually sticks, because you will be exporting to that same folder every working day. I set this up once per machine and forget about it.
- Last resort, relax Protected View. Same Trust Center, Protected View section. Unticking those boxes will get your file open, but it strips a genuine security layer off every document you touch afterwards. If you receive files from outside, and you do, use a trusted location instead.
If the file really is broken
Then it is an OmegaT problem after all, and here is the order of operations:
- Fix the tags. Ctrl+T, Check Issues, correct every flagged segment.
- Re-run Create Translated Documents. Nothing is lost by regenerating. Your translations live in the memory.
- Still broken? Clean the source with CodeZapper or a LibreOffice ODT round trip, reload the project, export again.
- Deadline tonight and nothing works? Use the Text Recovery converter the dialog suggests. In Word, hit Open, click the arrow beside the Open button, and choose Open and Repair. You will usually get the text back with the formatting flattened. That is a rescue, not a deliverable. Fix it properly afterwards.
Worth carrying with you
A .docx can be a valid ZIP full of well-formed XML and still fail Word's schema check. Any program that writes Word files directly, OmegaT very much included, can produce something that unzips cleanly but Word rejects. So "the ZIP opened fine" proves less than you would think. LibreOffice remains the better test.
Two smaller things that catch people out
Document properties do not get translated by default. The title, subject, and author fields live in a separate part of the archive. OmegaT has a filter option to include them, but it ships switched off. If your client checks document metadata, turn it on before you deliver.
Close the file in Word before you export. Word holds a lock on open documents and scatters ~$ temp files around. OmegaT has ignored those temp files since 5.7, but a locked target file will still block the write. Close Word first. It takes a second.
My pre-export routine
Five steps, in this order, on every job. They prevent nearly every Word export failure worth worrying about.
- Clean the source .docx before starting. CodeZapper, or a round trip through LibreOffice ODT.
- Keep filenames boring. No spaces, no apostrophes, no accents. You will thank yourself at export time.
- Never delete or reorder tags. Copy them across intact, and put nothing before the opening tag.
- Run Ctrl+T and Check Issues before creating target documents. Every time, no exceptions.
- Export to a plain local folder, not straight into a sync folder, then close Word, then open the result and actually look at it.
If Word still refuses to cooperate, remember the ten-second triage: open it in LibreOffice. That one test tells you whether you are fixing tags or fixing trust settings, and knowing which is most of the battle.
And keep your untouched source file. Always. If an export goes sideways you regenerate from the project. You never re-translate anything, because every segment you confirmed is already sitting in the memory.
OmegaT 6.1 is a well-maintained release with a hundred fixes behind it, and it is free in a market where the alternatives are emphatically not.
The tags are not your enemy. They are what buys you your formatting back. The day you stop fighting them is the day the tool gets out of your way.
