How to pick the right React i18n library

React ships no i18n primitive. The library you pick on day one decides how translations are stored, how they reach the bundle, and how much of the work stays yours for the next few years. Most teams pick by popularity, then discover the trade-offs at 2,000 keys.

This guide goes the other way: answer a few questions about your project first, then map the answers to the libraries that fit. It focuses on plain React (Vite, React Router, TanStack Start). Next.js has its own constraints, covered in the Next.js comparison.

Table of Contents

Six questions to answer before comparing libraries

A feature table is useless without knowing which rows matter to you. Go through these first.

1. How is the app rendered? SPA only, SSR with hydration, or React Server Components. Context-based hooks work everywhere in an SPA. With RSC, a hook forces "use client" on every component that renders text, so you will need a server-side API too.
2. Who writes the translations? Developers, an in-house team using a TMS, an agency delivering ICU files, or an AI pipeline. This dictates the catalog format more than any API detail.
3. How many locales and pages? Two locales and five pages can afford to ship everything. Ten locales and fifty routes cannot, and the loading strategy becomes the main cost.
4. Do you need types on keys? A typo in t("checkout.totl") compiles in every key-based library unless you wire the types yourself. Decide whether that is acceptable.
5. What does the string contain? Plain text, plurals, or sentences with a <Link> in the middle. Rich content is where most APIs get awkward.
6. How long will the project live? A three-month prototype and a five-year product do not need the same amount of build tooling.

Write the answers down. Everything below refers back to them.

The landscape in one picture

Fifteen years of JavaScript i18n fit in four architectural waves, and the React libraries you will compare come from different ones.

The history of JavaScript i18n details how each wave answered the previous one's problems.

The decision that matters most: where content lives and when it loads

Every React i18n library has the same shape: a store, a provider, a hook. Whatever the provider receives ends up in the client bundle or in the hydration payload. So the two structural choices are:

• Centralized or scoped content. One en.json for the app, or one declaration per component (or per namespace).
• Static or dynamic import. Everything bundled at startup, or the active locale and route fetched on demand.

The graph below estimates the payload for a theoretical app of 1 to 10 pages, translated into 1 to 10 locales, with about 30 KB of text per page.

Centralized content with static imports grows with both axes: 10 pages times 10 locales is 300 KB of text on every page. Dynamic imports remove the locale axis. Scoping removes the page axis. Only the combination stays flat.

This is not a library property, it is a discipline property. react-i18next can be scoped with namespaces and lazy backends. use-intl can be split per route. But nothing enforces it, and a shared <Button> reaching for t("common:cta") quietly makes common a dependency of every route. The benchmark measures this as "leakage from other routes" and "leakage from other locales", and it is where most of the gap between libraries comes from.

If your answer to question 3 was "many locales, many pages", weigh this section more than any API preference. The per-component vs centralized i18n post goes deeper on the maintenance side of the same choice.

The candidates

Library sizes come from the TanStack Start benchmark: provider plus hook in an empty component, after bundling, tree-shaking and minification, 10 pages and 10 locales. Content is measured separately.

Numbers are a snapshot at the benchmark's versions and change with releases. Run the benchmark on your own app before deciding on size alone.

Two things the table does not show. Paraglide ships almost no library because it generates code into your repo, which means a regeneration step before every commit and merge conflicts on generated files. And Intlayer requires a bundler plugin (vite-intlayer or equivalent), so it cannot run in a no-build setup.

Match your answers to a library

Where each library falls short

Honest limits, since every option has them.

• react-i18next: heaviest of the set, its own plural format, types are your wiring to maintain, dead keys accumulate silently.
• react-intl: verbose DX (useIntl() then formatMessage({ id })), global instance tied to many nodes.
• use-intl: simple to start, painful to optimize. Namespaces, dynamic loading and types together slow development a lot.
• Lingui: extra extract / compile build step, several overlapping syntaxes (t(), tagged template, i18n.t(), <Trans>) that confuse both humans and AI assistants.
• Paraglide: generated files in the repo, tree-shaking did not take effect in the React benchmark, and the locale is read from storage on every node rather than from a store.
• Tolgee: no key types, harder onboarding, in-context editing is the selling point.
• Intlayer: mandatory build plugin, smaller ecosystem, partial ICU support, content spread across the codebase by design so exporting one JSON for a translator needs tooling.
• gt-react, lingo.dev: not recommended in the benchmark: quota errors at build, vendor lock-in, and reactivity issues that required forcing provider re-renders.

What each option looks like in code

The same component, a cart summary with a title and a plural, written with each candidate. The interesting part is not the component, it is where the content lives and what the type checker knows about it.

{
  "title": "Your cart",
  "items_one": "{{count}} item",
  "items_other": "{{count}} items"
}

import type { FC } from "react";
import { useTranslation } from "react-i18next";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const { t } = useTranslation("cart");

  return (
    <section>
      <h2>{t("title")}</h2>
      <p>{t("items", { count })}</p>
    </section>
  );
};

{
  "cart.title": "Your cart",
  "cart.items": "{count, plural, one {# item} other {# items}}"
}

import type { FC } from "react";
import { FormattedMessage, useIntl } from "react-intl";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const intl = useIntl();

  return (
    <section>
      <h2>
        <FormattedMessage id="cart.title" />
      </h2>
      <p>{intl.formatMessage({ id: "cart.items" }, { count })}</p>
    </section>
  );
};

{
  "Cart": {
    "title": "Your cart",
    "items": "{count, plural, one {# item} other {# items}}"
  }
}

import type { FC } from "react";
import { useTranslations } from "use-intl";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const t = useTranslations("Cart");

  return (
    <section>
      <h2>{t("title")}</h2>
      <p>{t("items", { count })}</p>
    </section>
  );
};

msgid "Your cart"
msgstr "Votre panier"

msgid "{count, plural, one {# item} other {# items}}"
msgstr "{count, plural, one {# article} other {# articles}}"

import type { FC } from "react";
import { Plural, Trans } from "@lingui/react/macro";

export const CartSummary: FC<{ count: number }> = ({ count }) => (
  <section>
    <h2>
      <Trans>Your cart</Trans>
    </h2>
    <p>
      <Plural value={count} one="# item" other="# items" />
    </p>
  </section>
);

{
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}

import type { FC } from "react";
import { m } from "../paraglide/messages.js";

export const CartSummary: FC<{ count: number }> = ({ count }) => (
  <section>
    <h2>{m.cart_title()}</h2>
    <p>{m.cart_items({ count })}</p>
  </section>
);

import { plural, t, type Dictionary } from "intlayer";

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({ en: "Your cart", fr: "Votre panier", es: "Tu carrito" }),
    items: t({
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
    }),
  },
} satisfies Dictionary;

export default cartSummaryContent;

import type { FC } from "react";
import { useIntlayer } from "react-intlayer";

export const CartSummary: FC<{ count: number }> = ({ count }) => {
  const { title, items } = useIntlayer("cart-summary");

  return (
    <section>
      <h2>{title}</h2>
      <p>{items(count)}</p>
    </section>
  );
};

Already on react-i18next, react-intl or Lingui? The compat adapters (react-i18next, react-intl, Lingui) alias the imports at the bundler level so the existing API keeps working while you move component by component. The migration guide covers the rest.

Before you commit

A feature table tells you what a library does today. These points tell you what living with it will be like.

Check repository activity.

Commits, issue response time, and whether the last minor release was this year. A sound design with no maintainer is a migration in waiting.

Do not pick by npm downloads.

The most installed library is the one that shipped first, not the one that fits a 2026 React codebase. Downloads measure history, not fit.

Ask who pays the maintainer, and what they sell.

i18next is backed by Locize. next-intl / use-intl, vue-i18n, svelte-i18n and Lingui are backed by Crowdin. Tolgee, Paraglide (inlang) and Intlayer each run their own platform. A vendor whose revenue is hosted translation has little reason to make translation free inside your toolchain. Intlayer is the only one of the set that ships AI translation through the CLI with your own API key, and a CMS you can self-host.

Is it AI-agent ready?

Agents still struggle with i18n: they forget locales, invent keys, and mix message syntaxes. Does the library ship Agent Skills or an MCP server so the agent can list, fill and test content? And is content loading optimized by default, or does someone have to review namespaces and lazy imports every quarter?

Type safety out of the box.

Not "can be typed with extra wiring" but "a wrong key fails tsc on a fresh install". Check what happens with a key that does not exist, and with a locale that is missing one translation.

Detection of unused content.

Catalogs only grow. Intlayer's build purges unused fields and logs them (build.purge). Paraglide gets there by architecture, since an uncalled message function is tree-shaken. Everything else leaves the sweep to you.

Developer experience.

Setup time to first translated string, an LSP or VS Code extension that shows the translation on hover and jumps to the declaration, a CLI for fill, test and push, and a way for non-developers to edit content (visual editor or CMS) without a pull request.

Frequently Asked Questions

Going further

• i18n library benchmark: bundle size, leakage and locale-switch timings and the TanStack Start report
• React i18n: how the provider model works and what it costs
• react-i18next vs react-intl vs Intlayer, feature by feature
• next-i18next vs next-intl vs Intlayer
• The history of JavaScript i18n
• Compiler vs declarative i18n
• Per-component vs centralized i18n
• How bundle optimization works at build time
• Set up i18n in a Vite + React app
• Same guide for Vue, Svelte and Solid