XLIFF 1.2 vs 2.0: Which Version Fits Regulated Translation?
Table of Contents
What is the direct answer on XLIFF 1.2 versus XLIFF 2.0?
XLIFF 1.2 and XLIFF 2.0 are not compatible. A file conformant to one cannot conform to the other. Use 1.2 where tools or legacy systems require it, such as Xcode. Use 2.x for new pipelines when every tool in the chain supports it. Validate every file after conversion and keep an audit trail of each exchange.
What are XLIFF 1.2 and XLIFF 2.0, and what is their scope?
XLIFF is the XML Localization Interchange File Format. It carries translatable content and metadata from one step of a localization workflow to the next. Content authors, translation tools, reviewers and publishing systems all read and write it.
XLIFF 1.2. XLIFF 1.2 was published as an OASIS standard in 2008. It became the most widely deployed version and is the default exchange format in many computer-assisted translation (CAT) tools and legacy systems.
XLIFF 2.0. OASIS announced approval of XLIFF 2.0 as an official OASIS Standard on 28 August 2014. The committee described it as modular, with streamlined handling of segmentation, annotation and inline markup.
XLIFF 2.1 and 2.2. Later releases stay in the 2.x line. XLIFF 2.1 became an OASIS Standard on 13 February 2018. XLIFF 2.2 adds a Plural, Gender, and Select Module and, according to the XLIFF 2.2 draft specification, keeps all valid 2.0 and 2.1 files valid as 2.2 files. In this article, “2.0” and “2.x” are used for the shared structure. The comparison between 1.2 and 2.x is therefore the practical decision.
Scope of this comparison: file structure, inline codes, metadata, compatibility, tool support, conversion, validation and the controls a regulated team applies. Regulated content includes medical device documentation, pharmaceutical submissions, legal files, financial disclosures and defense manuals.
How do the structure, inline codes and metadata differ?
Document structure
In XLIFF 1.2, segments are delimited with mtype="seg" elements inside separate source and target containers, linked by an mid attribute. In XLIFF 2.0, segments sit inside units, and each segment holds a source and a target. This removes the need to match elements across containers.
Modularity
XLIFF 2.0 separates a mandatory Core from optional modules. A tool supports the Core and adds only the modules it needs. Examples of modules include Metadata, Matches and Glossary. XLIFF 1.2 has no module concept. It relies on extension mechanisms that tools use in different ways.
Inline codes
XLIFF 1.2 has a large set of inline elements. XLIFF 2.0 replaces it with a smaller and stricter set (pc, ph, sc, ec) that uses unique IDs and supports better nesting and protection of tags. Tag protection matters in regulated content. A lost or moved tag in a dosage table or a warning label changes the meaning of the published document.
Notes and metadata
XLIFF 2.0 adds categorized notes, while XLIFF 1.2 has a single generic note element. Categorized notes let a team separate translator queries from reviewer comments and from terminology guidance. This helps when each note type has a different owner.
Summary table
Criterion | XLIFF 1.2 | XLIFF 2.x |
Standard status | OASIS Standard, 2008 | OASIS Standard, 2.0 in 2014, 2.1 in 2018 |
Segment model | Segment markers in separate source and target containers | Units holding segments, each with source and target |
Architecture | Single schema with extensions | Mandatory Core plus optional modules |
Inline elements | Large set | Smaller, stricter set with unique IDs |
Notes | One generic note | Categorized notes |
Cross-version compatibility | Not compatible with 2.x | Not compatible with 1.2 |
Typical strength | Broad legacy tool support | Cleaner structure for new pipelines |
Are XLIFF 1.2 and 2.0 compatible?
No. The XLIFF 2.0 specification states that files conformant to one version cannot be conformant to the other. It also states that applications needing both must implement them as separate, independent functions.
Three consequences follow:
A 1.2 file opened in a 2.0-only tool fails or is read incorrectly.
A tool that claims “XLIFF support” without naming a version has not confirmed compatibility.
Conversion is a transformation of the content model, not a rename. It needs validation.
The XLIFF 2.2 draft keeps compatibility inside the 2.x line only. It does not extend compatibility to 1.2.
Which tools and frameworks support which version?
Support is uneven. Confirm it per tool and per version before committing to a format.
OpenXLIFF Filters support XLIFF 1.2, 2.0, 2.1 and 2.2. They provide conversion and validation. Extra Java validation covers the 2.0 Core and the Metadata, Matches and Glossary modules.
Unity Localization package offers an interface-based layer that handles both 1.2 and 2.0 through one API.
TYPO3 v14 and newer support both formats and detect the structure automatically.
Xcode does not support XLIFF 2.0 as of 2026, so iOS localization workflows use XLIFF 1.2.
Tool vendors change support between releases. Record the tool name, release number and supported XLIFF version in the workflow documentation.
What are the steps to choose, convert and validate, with owners and controls?
Step 1: Inventory the toolchain
Owner: localization manager.
Action: list every system that reads or writes XLIFF: content management, CAT tool, translation management system, QA tool, publishing.
Control: a versioned register of tool, release and XLIFF version supported.
Step 2: Select the version
Owner: localization manager with the engineering lead.
Action: apply the decision criteria below. Choose one version per pipeline.
Control: a written decision record with the reasons and the review date.
Step 3: Convert where required
Owner: localization engineer.
Action: use a conversion tool such as OpenXLIFF to convert between 1.2 and 2.x. Keep the original file unchanged.
Control: access control on the originals and a stored hash of each source file.
Step 4: Validate the result
Owner: localization engineer.
Action: run XML Schema validation, then the additional Java checks for XLIFF constraints that the schema cannot express.
Control: a validation report attached to the job record. A failed file does not move forward.
Step 5: Check content integrity
Owner: quality lead.
Action: compare segment counts, inline code counts, placeholders, numbers and terminology between the source and the converted file.
Control: an automated QA check with documented thresholds, plus a sample review by a subject-matter linguist.
Step 6: Record the exchange
Owner: project manager.
Action: log who sent each file, which version, when, and which tool processed it.
Control: an audit trail that supports the quality management system.
What decision criteria separate XLIFF 1.2 from XLIFF 2.0?
Crowdin’s guide recommends XLIFF 1.2 for iOS projects or where maximum tool compatibility is needed, and XLIFF 2.0 for new pipelines where the whole toolchain supports it. That source is a vendor guide. Treat it as a practical rule and confirm it against your own tools.
Use these criteria in order:
Platform constraint. If Xcode generates or consumes the files, use 1.2.
Weakest tool in the chain. The least capable tool sets the version. One 1.2-only CAT tool is enough to keep the pipeline on 1.2.
Legacy assets. Existing integrations, connectors and scripts written for 1.2 have a migration cost. Estimate it before moving.
Inline code risk. If content has dense markup, such as structured product labeling or software strings with placeholders, the stricter 2.x inline model reduces tag errors.
Metadata needs. If you need categorized notes, glossary or match information inside the file, 2.x modules provide a defined place for it.
Validation capability. Choose the version that your validators cover. Without validation, neither version is safe.
Longevity. New tooling investment tends to favor 2.x. Plan the 1.2 exit date, and do not assume one.
What examples show the choice in practice?
Example 1: iOS app for a medical device
A manufacturer localizes the companion app for a connected device. Xcode exports 1.2. The team keeps 1.2 for the app strings. Instruction-for-use documents run in a separate pipeline.
Example 2: New documentation pipeline
A software company builds a documentation workflow from scratch. All selected tools list 2.x support, and the team validates files with a tool that covers the 2.0 Core and modules. The team chooses 2.x and records the supporting tool releases.
Example 3: Mixed environment
A bank has a legacy CAT tool that reads only 1.2 and a new platform that writes 2.x. The team converts at the boundary, validates after every conversion, and runs the segment and tag count check. A named engineer owns the converter and its version.
What are the failure modes and mitigations?
Failure mode | Effect | Mitigation |
A 2.x file sent to a 1.2-only tool | Import error or silent data loss | Version register and a version check at intake |
Conversion drops or reorders inline codes | Broken tags, altered meaning in labels or warnings | Tag count QA and schema validation after conversion |
Segmentation changes during conversion | Translation memory matches fail, cost rises | Compare segment counts and test matching on a sample |
Notes or metadata lost | Reviewer queries and terminology guidance disappear | Map notes explicitly and verify after conversion |
Unvalidated files in production | Defects reach the published document | Gate: no file proceeds without a passing validation report |
Uncontrolled file transfer | Confidential content exposed | Access control, encrypted transfer, retention rules |
Public cloud conversion tools used on confidential files | Data leaves the controlled environment | Use tools within a private environment and review data processing terms |
For regulated content, data handling is part of the format decision. XLIFF files contain the full source text. Treat them with the same classification as the documents they carry. Our related article covers risks of machine translation for security and compliance.
Perspective: what we see in regulated projects
We treat the XLIFF version as an interface contract, not a preference. Most problems we see at handoff come from an unrecorded version, not from the format itself. A file that is valid XML can still carry broken inline codes after a conversion.
Our position is simple. Pick one version per pipeline. Write down which tool reads and writes it. Validate every file at each boundary. Keep the original untouched. Where translation memories and term bases exist, integrate them before the first file moves, so that terminology governance applies to every segment.
For regulated sectors, the format sits inside a wider system of controls: ISO 17100 for translation services, ISO 18587 for post-editing, ISO 27001 for information security. The file format is one control point among them. Our overview of globalization, internationalization and localization places it in that wider context.
— Eric Brown
Where does AD VERBUM fit?
AD VERBUM provides AI+HUMAN hybrid translation and localization for technical, legal, medical, finance, defense and manufacturing content. Work runs on a proprietary LangOps System hosted on EU servers, with subject-matter expert review, client Translation Memory and Term Base integration, and certifications that include ISO 17100, ISO 18587, ISO 27001 and ISO 42001, audited by Bureau Veritas. See our translation and localization services.
Pricing is set by quote and depends on scope.
What are the key points?
XLIFF 1.2 (OASIS Standard, 2008) and XLIFF 2.x (2.0 approved in 2014) are not compatible.
XLIFF 2.0 uses units with segments, a Core plus optional modules, and a stricter inline element set.
XLIFF 2.0 adds categorized notes. XLIFF 1.2 has one generic note.
The weakest tool in the chain, such as Xcode with 1.2, sets the version.
Convert with a dedicated tool, then validate with schema and additional checks.
Compare segment counts, inline codes and terminology after every conversion.
Keep originals under access control and log every exchange in an audit trail.
Treat XLIFF files as confidential content and keep processing in controlled environments.
FAQ
Is XLIFF 2.0 a newer replacement for XLIFF 1.2?
XLIFF 2.0 is the newer standard, but it is not a drop-in upgrade. The two versions are not compatible and need separate handling. Many tools still depend on 1.2, so migration is a project, not a setting.
Can I convert XLIFF 1.2 files to 2.0 without losing data?
Conversion is possible with filter tools such as OpenXLIFF. Loss is possible where 1.2 features have no direct 2.x equivalent. Validate the result, then compare segment counts, inline codes and notes against the original.
Does iOS localization work with XLIFF 2.0?
As of 2026, Xcode does not support XLIFF 2.0, according to Crowdin’s guide. iOS workflows therefore use XLIFF 1.2. Confirm this against your current Xcode release.
What changed in XLIFF 2.1 and 2.2?
They extend the 2.0 line and keep 2.0 files valid. XLIFF 2.2 adds a Plural, Gender, and Select Module. Neither makes 2.x compatible with 1.2.
Sources