Data format

XLIFF converter

A .xliff file is an XLIFF document written with the long extension, most often at version 2.0 — the redesigned OASIS standard in which each translatable string is a unit containing one or more segments, each with its own source and target. The payload matches the .xlf form; the structure is what changed.

Private for supported formats — processed in your browser

Convert supported files

Runs on your device

Drop XLIFF files here

Batch files can each use a different output. Nothing uploads for local conversions.

Working inputs include camera RAW, browser-local audio/video, PDF, CBZ/CBR comics, office documents, ebooks, markup, 3D models, structured text, images, and archives.

Where XLIFF comes from

OASIS published XLIFF 2.0 in 2014 as a deliberate break from 1.2, replacing an accumulation of optional attributes with a small mandatory core plus named modules for translation candidates, glossaries, metadata and change tracking. Adoption has been slower than the redesign deserved, because 1.2 works and trading partners are conservative — so in practice the two coexist, and the long .xliff extension has become a loose signal that a file is the newer shape.

How XLIFF works

  • The root xliff element carries srcLang and trgLang, replacing 1.2's source-language and target-language on file.
  • A unit contains segments, which makes sentence-level segmentation a first-class concept rather than a convention.
  • Functionality beyond the core lives in explicit modules, each with its own namespace, so a consumer can declare what it supports.
  • Inline markup uses a smaller, better-specified element set than 1.2's overlapping g/x/bpt/ept vocabulary.
  • Being XML, it carries the same external-entity risk as any other XML input and must be parsed without resolving them.

When to use XLIFF

  • Interchange with tooling built against the 2.0 core
  • Work where segmentation must survive the round trip, not just whole strings
  • Projects that need change tracking or glossary data alongside the translations
  • Normalising a mixed pile of localisation files into one modern representation

Strengths and limitations

Strengths

  • A much cleaner specification than 1.2, with a genuinely small mandatory core
  • Modules make optional capability explicit instead of implied
  • Segment-level structure models how translators actually work

Limitations

  • Less widely supported than 1.2 despite being the newer standard
  • Sharing the XLIFF name with an incompatible schema causes real interchange failures
  • Still verbose compared with a flat key-value catalog

Compatibility

Support is good in modern translation management systems and patchier in older desktop tools, so 1.2 remains the safer choice when a recipient's capabilities are unknown. Novus Convert parses 2.0 units and segments alongside 1.2 trans-units, refuses documents with a doctype or custom entities, and converts locally to the other nine localization formats.

Unit identifiers, source and target text and the declared languages are preserved. Module data — change tracking, glossary entries, translation candidates — and inline markup are not represented in flat key-value targets.