TMX File Format Explained: How Translation Memories Move Between CAT Tools

Every translation memory eventually needs to move. An agency switches CAT tools, a client asks for their TM back, a freelancer joins a project running on different software. The TMX file format exists for exactly this moment: it is the industry-standard way to carry translation memories between CAT tools without being locked into any vendor's database. We've helped agencies through enough TM migrations to know that the format itself is the easy part. The hard part is everything around it: segmentation rules, language codes, formatting tags. This guide covers both.

What the TMX file format actually is

TMX stands for Translation Memory eXchange. It's an XML-based standard for storing and transferring translation memory data, first published in 1998 by OSCAR, a special interest group of the Localization Industry Standards Association (LISA). The version you'll meet in practice is 1.4b, released in 2005. LISA shut down in 2011, and the Globalization and Localization Association (GALA) has kept the specification publicly available since. Nothing has replaced it. A standard frozen for two decades sounds like a problem, but in this case it's the reason the format works: every CAT tool vendor has had twenty years to get their import and export right.

Here's why the format matters. Inside your CAT tool, the translation memory lives in a proprietary database. Trados stores TMs as .sdltm files built on SQLite. memoQ has its own internal format. Smartcat, being browser-based, holds TMs inside your workspace rather than in local files. None of these can read each other's databases directly, and none of them should have to. TMX is the neutral snapshot: you export your TM to a TMX file, and any other tool can read the translation units back in.

We'd describe TMX as boring in the best possible way. It's verbose, it's XML, and a 500,000-unit TM can produce a file over a gigabyte. But it opens in a text editor, which means you can inspect it, fix it with search and replace, and diagnose problems without special software. When an agency owner asks us whether their fifteen years of TM data is portable, the answer is yes, precisely because of this unglamorous format.

One caveat: TMX carries translation units, not tool configuration. Segmentation rules, penalty settings, and QA profiles stay behind. That distinction explains most of the surprises people hit during migration, which we'll get to below.

Inside a TMX file: how the structure works

A TMX file has two parts: a header and a body. The header records where the file came from: which tool created it (creationtool), the source language (srclang), and how the text was segmented (segtype, usually "sentence"). The body holds the actual data as a list of translation units.

Each translation unit is a <tu> element. Inside it sit two or more <tuv> elements, one per language, each carrying an xml:lang attribute like "en-US" or "de-DE". Inside each <tuv>, a <seg> element holds the text itself. A minimal unit looks like this:

<tu creationdate="20260312T091500Z" creationid="anna.k">
  <tuv xml:lang="en-US">
    <seg>Press the release valve before opening the housing.</seg>
  </tuv>
  <tuv xml:lang="de-DE">
    <seg>Betätigen Sie das Ablassventil, bevor Sie das Gehäuse öffnen.</seg>
  </tuv>
</tu>

The attributes deserve attention. creationdate and creationid tell you who translated the segment and when. changedate and changeid track edits. Some tools add custom properties for client, project, or domain through <prop> elements. This metadata is what separates a well-maintained TM from a pile of sentence pairs: when two stored translations conflict, the dates and author IDs are how you decide which one to trust.

A practical habit we recommend to every project manager: after any export, open the TMX in a text editor and read the first fifty lines. Check the srclang value, check the xml:lang codes on a few units, and confirm the text isn't garbled. This takes two minutes and catches most transfer problems before they cost anyone a weekend. You don't need to understand XML deeply; you need to recognize when a language code says "en" where your target tool expects "en-GB".

TMX compatibility levels and why formatting tags cause trouble

The TMX specification defines two levels of compatibility, and the difference explains a lot of migration disappointment.

Level 1 means plain text only. The segment text transfers, and any inline formatting (bold, italics, index markers, footnote anchors) is stripped out. Level 2 means inline markup travels along inside the segments, wrapped in TMX tag elements like <bpt>, <ept>, and <ph>.

Level 2 sounds better, and in theory it is. In practice, every CAT tool represents formatting internally in its own way. A bolded product name in a Trados segment becomes a pair of tags that memoQ has to map onto its own tag model during import. Sometimes the mapping is clean. Often it isn't, and the imported unit carries tag placements the new tool treats as different from the incoming document's tags. The stored translation still exists, but it surfaces as a 90% fuzzy match instead of a 100% match, because the tags don't line up.

What this means for planning depends on your content. For running prose (contracts, reports, manuals with light formatting) the tag problem is minor, and even a Level 1 export keeps most of the reuse, since fuzzy matching works on text. For software strings, UI documentation, or anything dense with placeholders and inline codes, expect a real drop in match rates after migration and price the first few projects accordingly.

This doesn't apply if you're staying inside one tool's ecosystem. Moving a TM between two Trados installations through TMX keeps the tags consistent because both ends share the same tag model. The trouble starts at the border between vendors, which is exactly where TMX gets used most.

How to move a translation memory between CAT tools

The mechanical steps are similar everywhere. In the source tool, export the full TM to TMX, including all metadata fields the export dialog offers. In the target tool, create a new, empty TM with the same language pair, then import the TMX into it. Import into an empty TM, not into a production one: if the import goes wrong, you throw away the container instead of untangling mixed data.

Then run a test before trusting the result. Take a project you completed recently in the old tool, analyze it against the new TM, and compare the match statistics with what the old tool reported. The two won't be identical, but they should be close. A large gap is a signal, and it usually points to one of the problems in the next section.

A case from our own work with an agency migration: a team moving roughly 800,000 translation units from Trados to memoQ ran their first analysis and got almost nothing above 74%. Panic, understandably. Fifteen years of TM data, apparently gone. The cause turned out to be language codes: the TMX carried "en" as its source language while the memoQ projects were set up as English (United Kingdom), and the sublanguage matching option was strict. One setting change and a reimport later, the analysis looked normal. Total data lost: zero. Total time lost to the wrong diagnosis: most of a week, because the first assumption was that the TM was corrupted rather than mislabeled.

That pattern repeats constantly. When a freshly migrated TM returns no matches, the file is almost never broken. Check the language codes first, then segmentation, then tags, in that order. The boring explanation is usually the right one.

What breaks during TM migration and how to prevent it

Language codes are the first suspect, as above. The second is segmentation, and it's subtler.

CAT tools decide where sentences end using segmentation rules, and the defaults differ between tools. One tool breaks after every colon; another doesn't. One treats "Fig. 3" as a sentence boundary; another has an abbreviation list that prevents it. Your TM stores units the way the old tool segmented them. If the new tool cuts the same document differently, a stored 100% match may never be found, because the new segment boundaries don't produce the same source text.

A second example from practice: a technical documentation team we worked with maintained annual updates of a 40,000-word maintenance manual. In their old setup, a typical yearly update analyzed at around 80% reuse from TM. The first update after switching tools came back at 63%, and nobody had touched the content strategy. The loss traced back to numbered lists and abbreviation handling: the new tool split several list items into two segments where the old one kept them whole. Adjusting the segmentation rules (via SRX exchange where both tools support it, or by hand where they don't) recovered most of the gap on the following update.

Beyond those two, watch for three smaller things. Custom metadata fields such as client names or project codes often don't map automatically, so check whether your target tool imported the <prop> values or silently dropped them. Duplicate and conflicting units multiply if you import several old TMs into one new one, so merge deliberately, newest first. And penalties: some tools apply an import penalty to units arriving from TMX, which quietly demotes everything to 99%. That one is a setting, not a data problem, and it's reversible.

Migration is also the natural moment to clean. A TM full of misaligned or outdated units doesn't get better by changing tools.

When TMX is the wrong vehicle

TMX solves tool-to-tool transfer. It's the wrong answer to several adjacent problems that get confused with it.

If a client asks for "their translations" and doesn't run a CAT tool, a TMX file is useless to them. What they want is a bilingual spreadsheet: source column, target column, one row per segment. Every CAT tool can produce something like this, and it opens in Excel on any machine.

If the content is terminology (approved term pairs rather than full sentences) the right container is a glossary or a TBX termbase, not a TM. Stuffing term pairs into a TM as tiny units is a workaround that pollutes match statistics.

And if the translation itself was produced outside a CAT tool, for instance in an AI translation workflow, you need a way to get those sentence pairs into your TM afterwards. This is a workflow we think about a lot, because we build for it. SnapIntel, our AI translation workflow product, returns every completed job with a neutral source/target XLSX export alongside the translated DOCX, XLSX, or PPTX, so the sentence pairs can be imported into whichever TM your CAT tool maintains. We chose a plain spreadsheet over TMX deliberately: bilingual Excel import exists in practically every tool, anyone can inspect it, and there's no tag model to argue with. You can see how the workflow fits together at snapintel.io.

The honest limitation: a spreadsheet is Level 1 by nature. No inline tags travel with it. For document translation that's rarely a problem; for heavily tagged software content, a proper TMX pipeline earns its complexity. And if your tool can't import bilingual Excel into a TM directly, converters exist. Okapi Olifant, a free TM editor, reads spreadsheet-shaped data and writes clean TMX.

A checklist for your next TM transfer

Before you move a TM between CAT tools, run through this list:

• Export the full TMX with all metadata, and archive a copy before touching anything.
• Open the file in a text editor. Verify srclang and the xml:lang codes match what the target tool expects, including regional variants.
• Import into a new, empty TM, never directly into production.
• Re-analyze a recently completed project in the new tool and compare match statistics against the old tool's numbers.
• If the gap is more than a few points, check language codes, then segmentation rules, then tag handling, in that order.
• Check whether custom fields survived the import before deleting anything on the old side.
• Keep the original TMX archived permanently. Storage is cheap; re-exporting from a decommissioned tool is not.

Budget half a day per language pair for a careful migration, and a full day for the first one while you learn where your particular pair of tools disagrees. The work is front-loaded: once the segmentation rules match and the codes line up, TMX transfers become routine, and your TM goes back to being what it should be, an asset that outlives any single piece of software.