XLIFF vs JSON vs PO vs ARB: Localization Formats Compared

Last reviewed: 4 October 2026

Short answer

Choose the format your application and translation workflow can support reliably. JSON is a data container with library-specific localization conventions; PO belongs to gettext workflows; ARB carries JSON-based resources and attributes; XLIFF is designed for localization interchange. A project can use one runtime format and another exchange format. Test the conversion in both directions before assuming keys, variables, context, review state and plural messages will survive.

Key takeaways

Start with the runtime and extraction pipeline, not a format popularity claim.
Specify versions and conventions rather than only file extensions.
Protect identifiers, variables and meaningful metadata.
Compare developer and translator needs together.
Test a representative round trip before a large batch.
Keep the original resources and a traceable change record.

What is the difference between runtime and exchange formats?

A runtime resource is consumed by the application or its build pipeline. An exchange file carries information between localization stages and tools. Those roles can overlap, but they should be named separately in the project brief.

A product may keep JSON resources in its repository, export them for translation, and import the result into the same key structure. Another product may use a structured interchange step because translators need notes, protected inline codes or review status. The application still needs a valid resource at the end.

Avoid treating conversion as a clerical operation. If an export retains only visible text, it can lose the context required to translate correctly. If an import ignores review status, the build may include unapproved work. The file workflow should preserve the information that the project's acceptance process actually depends on.

What does each format provide?

Each format has a different role and set of conventions. Identify that role before comparing convenience. The following table is a planning summary; actual compatibility depends on the named tool and version.

Format	Main structural basis	Context approach	Message behavior	Key compatibility question
XLIFF	XML localization interchange	Notes, structural information and supported modules	Protected inline content and workflow information	Which XLIFF version and modules survive import and export?
JSON	General structured data	Separate brief or agreed resource convention	Defined by the localization library	Does the tool understand this project's keys and tokens?
PO	gettext message catalog	Comments, references and message context	gettext plural entries and format conventions	Does the extraction, merge and compilation chain agree?
ARB	JSON resources with associated attributes	Resource metadata and descriptions	Depends on the consuming framework	Does the generator accept the message and placeholder schema?

OASIS XLIFF 2.1 defines a vocabulary for moving localizable data between process steps.[1] RFC 8259 defines JSON as structured data, rather than a localization workflow.[2] GNU's PO documentation describes original and translated message entries with comments and flags.[3] The ARB specification associates resource entries with optional attribute entries.[4]

These distinctions do not establish a universal winner. A simple catalog with strong external context can work well; a richer format can still fail if the importer discards the fields the team needs. Decide which information is essential and prove its preservation.

When is JSON a practical choice?

JSON is practical when the application already uses a documented resource schema and the team can validate that schema. Its readable key-value structure can make repository reviews straightforward. Its simplicity also means the project must define many localization behaviors elsewhere.

Specify whether resources are flat or nested, what characters separate keys, which values are translatable and how interpolation works. Do not assume a tool that accepts “JSON” understands the particular library's plural suffixes or message syntax. Supply representative files rather than relying on a checkmark in a format list.

Use stable key paths and external context where ordinary JSON cannot carry comments. If a project adds metadata objects, confirm that both the runtime and the translation tool know how to treat them. A translator should not have to guess whether a number is a configuration value or a user-facing string.

The main test is behavior after re-import. Missing keys, renamed tokens and wrong return types can exist in perfectly parseable JSON. Run the application's lookup and rendering checks in addition to syntax validation.

When does PO fit the project?

PO fits a gettext-based workflow where extraction, translation updates and resource compilation are already part of the product. Keep the message identity and context coherent with the source code. The editable catalog is a handoff artifact, not merely a spreadsheet of translated sentences.

GNU's documentation distinguishes the original msgid from the translated msgstr, and describes extracted comments, source references and flags.[3] Those fields give reviewers clues about where the message appears and how it should be checked. Do not strip them just to make the file smaller.

Assess how changed source messages are merged into translated catalogs. A source edit can change the identity or require renewed review. The team needs a policy for unreviewed, missing and obsolete work, rather than assuming that any nonempty translation is ready for release.

Check the entire gettext chain: extraction markers, context, format arguments, language header and compilation. Confirm the application's loading behavior. A successful translation-tool export alone does not prove the catalog was compiled or used by the product.

When should a team use ARB?

Use ARB when the consuming platform or generator expects ARB resources and the required attributes can be preserved. In Flutter projects, the official internationalization guide describes ARB messages, placeholder metadata and generated localization accessors.[5] Follow the project's actual generator configuration.

A message identifier and its associated metadata work together. Descriptions can explain whether a phrase is a button, a state or an instruction. Placeholder definitions can tell the tool what input the generated message method expects. Do not translate those identifiers as though they were visible text.

Plural and select expressions need message-level validation, not just JSON parsing. An expression can be stored as a valid JSON string and still be rejected by the generator. Review placeholder types, mandatory branches and escaping under the framework's documented syntax.

ARB is not interchangeable with every plain JSON catalog. A converter that keeps only message strings may discard descriptions and placeholder definitions. Record which metadata is required for generation and which is needed for linguistic review, then check both after export and import.

When is XLIFF worth the added structure?

XLIFF is useful when the exchange workflow benefits from explicit source and target units, notes, protected inline content or supported process information. Agree the version and profile with both sides. “Supports XLIFF” is too broad to establish that a particular document will round-trip safely.

OASIS specifies XLIFF 2.1 core structures and additional modules.[1] This article uses that named specification as a reference, without claiming it is the latest version supported by every tool. A system accepting one version or module set should be tested with the export you actually plan to use.

Choose an exchange profile deliberately. List the identifiers, notes, states, inline codes and metadata the receiving tool must retain. If information is stored in an extension, confirm the tool does not silently drop it. The project's use of the format should be explicit enough for the next reviewer to reproduce.

Keep source resources and conversion mappings. The XLIFF file may not by itself contain everything required to reconstruct the application resource. Reassembly should return translations to the correct identifiers while preserving protected content and respecting approved workflow status.

How do developer and translator needs compare?

Developers need resources that build and behave predictably; translators need enough context to make accurate choices. Reviewers need traceability and approval evidence. A practical choice serves all three roles rather than optimizing only the appearance of the file.

The following original decision matrix connects a requirement to the next verification step. It does not score tools or claim performance benchmarks.

Project requirement	First option to examine	What to prove
Existing JSON runtime	Current JSON conventions	Tokens and keys remain valid after translation
gettext application	PO extraction and merge workflow	Catalog identity and format checks survive
Flutter generated messages	ARB configuration	Metadata and expressions pass generation
Rich localization exchange	Agreed XLIFF profile	Required notes, codes and states are retained
Frequent source changes	Existing format with a stable update process	New and changed messages receive review
Many translation vendors	Documented exchange contract	Each vendor round-trips the representative fixture
Strict repository review	Predictable serialization of chosen format	Diffs show meaningful changes without hiding data loss
Rich text or dynamic messages	Runtime-native message syntax	Protected content and branches behave in the product

Ask reviewers to work on the same representative fixture. Include a short button, a long error, a named variable, a plural message, a note and a changed source entry. Observe the imported result, not only the translator's editing screen.

How should teams test interoperability?

Run a controlled round trip with a small set of representative resources before translating the whole product. Export, edit, import and rebuild using the intended tools. Preserve the original files so every difference can be inspected.

Compare stable identities, source text, translated values, protected tokens, notes, states and plural branches. Record intentional transformations, such as serialization order, separately from loss of meaning. If the conversion changes a key or drops a placeholder definition, resolve that contract failure before scaling the workflow.

Use a three-layer acceptance model: file validity, information preservation and product behavior. XML or JSON parsing addresses the first layer. A comparison of before-and-after fields addresses the second. Loading, rendering and task testing in the application addresses the third.

Do not call a format fully interoperable because one sample opened successfully. Include edge cases relevant to the real product and the exact tool versions. Keep a record of unsupported features and decide whether to change the profile, use another tool or maintain additional context outside the exchange file.

How can version control and maintenance stay manageable?

Keep resource changes reviewable and separate unrelated updates. Agree consistent serialization and file grouping so reviewers can see what changed. Avoid wholesale key renaming during a translation update unless it is an intentional, tested migration.

Store the source revision, target language and tool profile with the handoff. Document how changed messages are detected and which status permits inclusion in the release. Review fallback behavior and missing translations explicitly. The process matters more than whether the file initially looks concise.

LocalizeZone recommends sharing sample files and the extraction or generation details when requesting software localization. Include the exchange tools, target languages and required review layers in the quotation request. That allows the scope to reflect conversion and QA needs rather than assuming translation alone covers them.

FAQ

Which format is best for every project?

There is no universal choice. Start with the runtime, required information and supported workflow, then test the representative round trip and application behavior.

Can JSON contain plural messages?

Yes, according to a library's schema or message syntax. JSON stores the data; it does not supply one universal plural-selection mechanism.

Is ARB just interchangeable JSON?

No. It is JSON-based but associates resources with attributes.[4] A consuming framework can require metadata and message syntax that a generic JSON importer does not preserve.

Does XLIFF compatibility guarantee metadata preservation?

No. Verify the version, modules, extensions and receiving tool. Include the fields you rely on in an actual export-and-import test.

Is opening a PO file enough to approve it?

No. Review context and translations, apply the project's format checks, and verify compilation and application loading in the intended workflow.

What should a supplier receive first?

Send representative resources, context, source revision, runtime details and required outputs. Include a small round-trip fixture before assigning a large batch.

Sources and methodology

Primary OASIS, IETF, GNU, ARB and Flutter documentation was checked on 4 October 2026. GNU's publicly available PO-entry documentation was read through a locally saved copy when the browser retrieval timed out. Comparison tables and acceptance steps are original planning frameworks. No vendor benchmark, cross-tool conversion experiment or application build was performed for this article.

References

[1] OASIS. XLIFF Version 2.1, OASIS Standard, 13 February 2018.

[2] IETF / RFC Editor. RFC 8259: The JavaScript Object Notation Data Interchange Format.

[3] GNU gettext manual. What an entry looks like.

[4] Google app-resource-bundle project. Application Resource Bundle Specification.

[5] Flutter documentation. Internationalizing Flutter apps.

XLIFF vs JSON vs PO vs ARB: Localization File Formats Compared