Lokalise vs Crowdin vs Phrase: A Developer’s Comparison

Lokalise, Crowdin and Phrase are the three names that come up in almost every "which TMS should we use" thread. They overlap enough that a feature-checklist comparison makes them look interchangeable, and they differ enough that picking the wrong one costs you a migration eighteen months later.

This is a developer-oriented read: what the CLI and CI story actually looks like, which file formats survive a round trip, how each handles two feature branches touching the same keys, how translators and agencies plug in, and how their pricing models differ – which matters more than any headline number. At the end there is a fourth option, Translatize, which models branches differently from all three.

Three tools, three different origin stories

Positioning explains most of the feature differences. All three drifted toward the middle over the years, but the centre of gravity is visible.

Crowdin

Crowdin is the oldest of the three, launched around 2009, and grew up around community and open-source localization. That heritage shows: crowdsourced translation, voting on suggestions, a free program for qualifying open-source projects, and a large integration catalog. If your localization involves volunteers or a public-facing translation portal, that is the workflow it was designed around. Crowdin Enterprise is the separately-sold tier for organizations that need SSO, workspaces and stricter access control.

Lokalise

Lokalise arrived later, in the second half of the 2010s, aimed at product teams shipping web and mobile apps. The emphasis is developer and designer ergonomics: a fast editor, screenshot and key context, a Figma plugin, an API-first design, and SDKs for over-the-air mobile string updates. Its defaults assume UI strings owned by engineers.

Phrase

Phrase started as PhraseApp in Germany around 2011, then merged with Memsource in 2021. The result is a two-product suite: Phrase Strings (key/value software localization, the PhraseApp lineage) and Phrase TMS (the Memsource lineage – a CAT environment for documents, translation memory and vendor workflows). If you localize a product and a stack of marketing PDFs, contracts or help-centre articles, Phrase covers both in one suite rather than treating documents as an add-on.

The developer workflow: CLI, API and CI

All three ship a real CLI, a documented REST API and git integrations. The differences are in the details.

Lokalise uses lokalise2 (a single Go binary) driven mostly by flags:

lokalise2 --token "$LOKALISE_TOKEN" --project-id "$PROJECT_ID" \
  file upload \
  --file locales/en.json --lang-iso en \
  --replace-modified --include-path

lokalise2 --token "$LOKALISE_TOKEN" --project-id "$PROJECT_ID" \
  file download --format json --unzip-to ./locales

Branch-aware calls append the branch to the project id, PROJECT_ID:feature-checkout, which is easy to template in CI.

Crowdin is configuration-first. A crowdin.yml in the repo root describes the source-to-translation mapping once, and the CLI stays terse:

project_id_env: CROWDIN_PROJECT_ID
api_token_env: CROWDIN_PERSONAL_TOKEN
base_path: '.'
preserve_hierarchy: true
files:
  - source: /locales/en/*.json
    translation: /locales/%two_letters_code%/%original_file_name%

crowdin upload sources --branch "$GIT_BRANCH"
crowdin download --branch "$GIT_BRANCH" --skip-untranslated-strings

The placeholder language (%two_letters_code%, %original_file_name%) handles awkward repo layouts – multiple locale folders, per-module bundles – without scripting.

Phrase Strings takes the same config-file approach with .phrase.yml:

phrase:
  project_id: PROJECT_ID
  file_format: nested_json
  push:
    sources:
      - file: ./locales/<locale_name>/index.json
        params:
          locale_id: <locale_name>
  pull:
    targets:
      - file: ./locales/<locale_name>/index.json

phrase push --branch "$GIT_BRANCH"
phrase pull --branch "$GIT_BRANCH"

For CI, all three document a GitHub Actions setup and work in any runner. Crowdin's GitHub integration is the most opinionated: it can maintain a long-lived translation branch and open pull requests as translations land, so strings arrive as reviewable diffs rather than a pull step someone forgets to run. Lokalise and Phrase both offer repo sync too; teams commonly drive them from their own workflow file instead, for more control over when merges happen.

On the API side, all three are conventional REST with token auth and are well documented. Lokalise's API maps closely onto its CLI; Phrase's is the largest surface because it spans two products; Crowdin's is versioned, with a maintained set of official clients.

File format coverage

For mainstream software formats – JSON (nested and flat), YAML, .properties, Android XML, iOS .strings and .stringsdict, Flutter ARB, gettext PO, XLIFF, RESX, CSV/XLSX – all three are comprehensive. Where they separate:

• Phrase goes furthest beyond software strings, because Phrase TMS brings document formats – DOCX, XLSX, IDML (InDesign), PDF and subtitle files – with segmentation and translation memory built for prose.
• Crowdin has the broadest long tail of niche and game-industry formats, plus handling for documentation sites and Markdown-heavy repos.
• Lokalise focuses on app and web formats, with preservation of plurals and placeholder syntax.

The real question is not "is my format on the list" but "does a push-then-pull round trip return a byte-identical file when nothing changed". Test that on a real file from your repo before you commit to any vendor – plural forms, ICU messages and comment preservation are where round trips break.

Parallel feature work: branches and versions

If two feature branches add and rename keys simultaneously, how does the platform cope? This is where a TMS either fits your git workflow or fights it.

Crowdin models this as versions management with branches. You push a named branch, translators work on it, and merging folds the strings back into the main project – "one project, many branches", wired to the GitHub flow. Duplicate strings across branches can be shared so you do not pay to translate the same string twice.

Lokalise has explicit branching that mirrors git: create a branch, translate in isolation, merge back with a conflict-resolution step. The project:branch CLI convention wires trivially to GITHUB_REF. Branching is gated to higher plan tiers.

Phrase Strings also supports branches with push/pull and a merge step, and Phrase TMS separately has job-level versioning suited to document rounds rather than feature branches.

An honest caveat for all three: none of them make branch merges free. Conflicts on the same key with different values still require a human decision, and long-lived branches accumulate drift exactly like code does. Short branches merged often wins regardless of vendor.

People: translators, vendors and permissions

Ordering translation and working with agencies

Crowdin leans hardest into community: proofreading roles, suggestion voting, translator leaderboards, and a marketplace of vendors and apps – a feature set aimed at open-source and community-driven projects.

Lokalise supports ordering translations from partner agencies inside the editor and suits in-house or small-agency teams. Screenshots and key context in the editor cut down the "what is this string for" round trips with non-technical translators.

Phrase is the most vendor-native. Because Phrase TMS descends from a professional CAT tool, LSPs already know it: translation memory leverage, term bases, QA checks, and the analysis reports agencies use to quote work. If your localization runs through a language services provider on a purchase order, that is the process it was built for.

Roles and permissions

All three offer role-based access – broadly an owner/admin tier, a manager tier, and contributor roles scoped to specific languages. Practical differences:

• Language-scoped contributors are standard everywhere; you can safely give a freelancer access to one target language only.
• Fine-grained controls, SSO/SAML, audit logs and multi-workspace separation generally sit in the enterprise tiers (Crowdin Enterprise, Phrase's higher plans, Lokalise's upper tiers). If you need SCIM or audit trails, assume an enterprise conversation with all three.
• Phrase's split between Strings and TMS means permissions are managed per product – more control, and more to administer.

How the pricing models differ

Prices change, so treat this as a description of shape, not numbers; check each vendor's pricing page before budgeting.

• Lokalise prices in tiers where the main dimensions are seats and hosted keys, with features (branching, advanced integrations, SSO) unlocked by tier. Cost scales with team size and key inventory.
• Crowdin prices in tiers driven by hosted strings and seats, and separately offers a free program for qualifying open-source projects. Crowdin Enterprise is quoted separately.
• Phrase is modular: Strings and TMS are licensed separately or as a suite, typically per seat plus a volume component (keys for Strings, words for TMS), commonly annual, with quotes at the upper end.

Two budgeting notes apply to all three. Machine-translation and AI usage is usually metered on top of the subscription. And seat definitions matter – check whether reviewers, developers who only run CI, and external freelancers consume a paid seat, because that one detail can double the effective cost.

Side by side

Choose Lokalise if…

Your localization content is app UI strings, engineers and designers own most of the workflow, and you want a short distance from git push to translated keys. The editor and design integrations reduce back-and-forth.

Choose Crowdin if…

You run an open-source project, rely on community contributors, or want translated strings to arrive as pull requests you review like any other change. Its config format handles messy repo layouts gracefully, and the OSS program removes the licence cost for qualifying projects. It also suits documentation-heavy products.

Choose Phrase if…

You have professional translation vendors, translation memory and terminology requirements, or content beyond UI strings – legal, marketing, support articles. Phrase TMS is a real CAT tool, and your LSP probably already uses it. Accept in exchange a larger surface to administer and an enterprise-style buying process; for a five-person startup translating a settings screen, it is more platform than you need.

Choose Translatize if…

Your translations change on feature branches and the thing that keeps going wrong is the merge, not the translating. You want to name the merge strategy rather than trust one, keep a translator inside a feature branch with no route to production copy, and issue a CI token that is bound to a single branch. Nine formats round-trip symmetrically, and the price is a published flat tier rather than a quote that moves when you add a reviewer. The next section covers what that actually looks like.

A fourth option: Translatize

All three platforms above support branches, and all three treat a branch as a version container: a snapshot you push strings into, work on, and later fold back. Translatize starts from the other end – the branch is the data model. Every label belongs to a branch, and reads and writes resolve against the branch the caller is on, rather than a branch name appended to a project id.

That has consequences. Merging is a first-class operation with four named strategies instead of one merge button: overwrite (a non-destructive union where the source wins on conflicting keys), replace (destructive – the target becomes a copy of the source), keep-newer (per-label timestamps decide each key), and manual (fetch the conflict list and resolve key by key). You choose per merge, so a routine feature merge and a "reset this branch from that one" operation are different commands rather than the same one used carefully.

Permissions follow the same model. Project roles are owner, admin, developer and translator: developer and above can create branches, only the creator or an admin can delete one, and only an admin or owner can merge into main. A translator can own a feature branch end to end with no path to production strings – the gate is structural, not procedural. CI tokens are scoped the same way: an integration token prefixed mcni_ is bound to one project and one branch, so a pipeline on a feature branch cannot write to main.

The rest is deliberately plain. Nine import and export formats, symmetric in both directions: JSON (nested or flat), YAML, CSV, XLIFF 1.2, gettext PO, Flutter ARB, .NET RESX, Android XML, iOS .strings. Review statuses of draft, review, approved and rejected. Label context fields – description, screenshot, character limit and location – for the "what is this string for" problem. WebSocket notifications when labels change, and webhooks on label and branch events. And a published flat price list – Free at $0 through Agency at $199/month – rather than a seat-and-volume quote.

Head-to-head breakdowns exist for Translatize vs Lokalise, vs Crowdin and vs Phrase; wider options are in the best i18n tools of 2026. Still deciding whether you need a platform at all? Translating JSON files with AI is a reasonable first pass.

Where Translatize fits

Run the round-trip test on Translatize the way you would on the others: import a real locale file, translate two strings, export, diff. Import and export cover the same nine formats in both directions – nothing is export-only – so a nested JSON bundle comes back nested, and an XLIFF 1.2 export still pairs each translation with its source text. The @translatize/cli handles the JSON pull/push loop on disk; the other eight formats go through the app or the REST API.

Then run the harder test. Branch per feature, translate in isolation, and merge with the strategy that matches the situation: overwrite for a routine union, keep-newer when both sides moved, manual when you want the conflict list before anything is written. The merge to main is gated to admins and owners, and the mcni_ token your pipeline uses is bound to one project and one branch, so CI on a feature branch cannot write outside it. The free plan – 1,000 source keys, one project, two branches, no card – is enough to run both.

Wrapping up

All three incumbents are mature, all have real CLIs and APIs, and all will handle your JSON. The choice among them is mostly about who does the translating: engineers and designers in a product team point to Lokalise, a community and an open-source licence to Crowdin, professional vendors and mixed content to Phrase.

Evaluate against your own workflow, not a feature matrix. Push one real locale file, translate two strings, pull it back and diff it. Then run the harder test: open two branches that touch the same keys, merge both, and look at what the tool does with the conflict and who it lets perform the merge. That second test is the one Translatize was designed around – the docs start with the branching model.