Compare · i18next

For React or Solid teams for whom key naming, JSON namespace maintenance, or raw-key fallbacks have become recurring workflow cost.

You already know what the string says.

i18next identifies messages by keys you invent, namespace, remember and keep in sync with a JSON tree. Palamedes identifies them by the source text you already typed. That single decision deletes a whole category of weekly work, changes what a missing translation looks like in production, and changes what lands in your translators' inbox.

Licence: MIT
Identity: Explicit keys + namespaces
Catalogs: JSON, key-based
Checked benchmark: up to 80× slower

i18next figures: i18next 26.3.4 / react-i18next 17.0.8, researched July 2026. Projects move; re-check before you decide.

Run the guided evaluation setup See the decision summary

01 — Decide

Choose the model that leaves you with less recurring work.

For the audience above, we recommend Palamedes. The alternative is not a disclaimer: if the right column describes your constraint, choose i18next and do not think twice about it.

Pick Palamedes when…

Key maintenance has become a chore, or raw keys have already leaked into production UI.
Your translators would rather receive .po files than nested JSON — most professional tooling would.
You want ICU semantics guaranteed end to end rather than swapped in via plugin.
Extraction time matters in CI: 80× on the checked realistic extract + catalog-update workflow against i18next-cli.

Pick i18next when…

You need i18n outside React and Solid — Angular, Vue, jQuery or plain Node.
You depend on the plugin ecosystem: specific backends, detectors, or post-processors.
You need an existing i18next-specific backend, detector or post-processor.

02 — Daily work

What changes after the choice is made.

These are workflow consequences, not a feature inventory: fewer conventions to maintain, one catalog boundary to review, and one runtime model to carry through the supported hosts. Each point maps back to an inspectable artifact.

A missing translation still reads like a sentence

When a key-based lookup misses, the UI can show the raw key to a user. Palamedes falls back to the source string, so the worst case is untranslated English rather than an identifier that looks like a crash. The fallback is the message you already wrote — there is nothing to configure and nothing to forget.

Inspect source-to-catalog and ICU proof →

No naming layer to maintain

Key-based workflows ask every developer to invent, namespace and remember identifiers, keep them in sync with a JSON tree, and review each other's naming in pull requests. Source-string identity deletes that job. You write the sentence, extraction finds it, and context disambiguates the rare genuine collision.

Inspect source-to-catalog and ICU proof →

ICU is the format, not a plugin

i18next ships its own interpolation syntax and treats ICU MessageFormat as an opt-in plugin that replaces it. Palamedes is ICU throughout — the same nested plural and select semantics travel from source through catalog to runtime, with a checked proof that they survive the trip rather than a claim that they should.

Inspect source-to-catalog and ICU proof →

Extraction is a compile step, not a convention

Palamedes parses your source in a Rust core instead of scanning by convention. On the checked realistic corpus that shows up against the current i18next CLI: 5818 ms vs 73 ms for i18next-cli on the same inventory.¹

Inspect source-to-catalog and ICU proof →

03 — i18next

Where the competitor is the stronger fit.

The strengths and trade-offs below are sourced from the dated research for i18next. They explain why the right decision can genuinely be i18next, even when Palamedes is our recommendation for the audience above.

Competitor strength

What i18next earned

A modular core and plugin architecture cover a wide range of runtimes, data backends, detectors and bundlers.
A modular plugin architecture covering nearly every backend, detector and bundler combination you are likely to need.
Genuinely framework-agnostic: the same core runs in React, Vue, Angular, Node and Deno, with ports outside JavaScript entirely.

Trade-off

What that inheritance costs you

The key-based model has a signature runtime failure: when a lookup misses, users see checkout.button.buy unless fallback behavior and source copy are configured separately.
Type-checking string keys has been expensive at scale — reported tsc slowdowns and out-of-memory crashes on large namespace sets, mitigated only recently, with three overlapping typing modes spanning v25 to v27.
RSC support lagged badly: next-i18next stayed Pages-Router-only for years after the App Router shipped, and the official guidance was to bypass it and wire react-i18next by hand — a gap competitors were built specifically to fill.

04 — Proof in code

The same button, two ideas of what identifies it.

i18next

// en/checkout.json
// { "button": { "buy": "Buy {{count}} seats" } }
 
const { t } = useTranslation("checkout")
t("button.buy", { count: seats })

Palamedes

import { plural } from "@palamedes/core/macro"
 
plural(seats, {
  one: "Buy one seat",
  other: "Buy # seats",
})

With i18next the JSON file is the source of truth and the component points at it — two places, kept in sync by discipline. With Palamedes the component is the source of truth and the catalog is generated from it.

05 — Side by side

The comparison, without the adjectives.

Where a row cites a measurement, it comes from the checked benchmark report in the repository. Where nothing was measured, the row says so.

Criteria	i18next	Palamedes
Message identity	Keys you invent and maintain	The source string plus optional context
Missing translation shows	The raw key, in production	The source text
Catalog format	JSON namespaces	.po (gettext), FCL opt-in
ICU MessageFormat	Opt-in plugin, replaces the native format	Native, end to end, with a checked proof
Extract + update, realistic corpus	5818 ms vs 73 ms	80.19× faster on realistic extract + catalog update¹
Framework reach	React, Vue, Angular, Node, Deno, and more	React and Solid, plus request-local i18n on Node servers
Ecosystem	Very large plugin and integration surface	Small and new — first-party adapters only

¹ Median of 7 runs on the realistic corpus (1,500 files, ~400k lines, 6,000 messages — half the files carry no i18n marker), one machine-local run, same semantic validation for every tool. The full report and the harness are in the repository, and the site build fails if these numbers drift from it.

06 — The trade-off

i18next reaches frameworks Palamedes does not support, its plugin ecosystem has no equivalent here, and there is no migration playbook from i18next yet — moving a key-based catalog to source-string identity is technical migration work you would be doing largely by hand today.

07 — Evaluate

Test the source-string boundary before planning migration

There is no documented i18next migration playbook yet because moving key-based catalogs to source-string identity requires project-specific decisions. Keep evaluation reversible: model one representative feature on a branch, inspect its PO output and runtime behavior, then decide whether a migration plan is warranted.

Run the guided evaluation setup Inspect source-to-catalog and ICU proof

08 — Questions

Questions teams ask before leaving i18next.

The migration, framework, catalog, runtime and trade-off boundaries are stated here and included in the page's structured data.

01Can we evaluate Palamedes without replacing i18next everywhere?

02Does Palamedes make sense if we use only one framework?

Yes, if the source-string, catalog and runtime model is the fit. Framework breadth is proof that the supported adapters share one model, not a requirement that one application use several frameworks. Check the supported host and its documented boundary before adopting.

03Who owns the catalogs?

Palamedes keeps source-string-first PO catalogs in the repository. Extraction, catalog updates, audits, merging and compilation are local workflow steps; it does not provide a hosted TMS or machine translation service.

04What runtime code reaches the application?

Transformed code reaches the active Palamedes instance through getI18n(). The exact adapter and compiled artifact depend on the supported host; inspect the framework documentation and proof rather than treating this comparison as a bundle-size claim.

05What do we give up by choosing Palamedes over i18next?

Make the next step match the decision you still need to make.

Run the guided evaluation setup Compare another model