![Diagram comparing where translation runs in the Next.js App Router. next-intl: createMiddleware handles locale detection, i18n/request.ts loads messages/${locale}.json per request, Server Components call getTranslations and render text to HTML, and NextIntlClientProvider passes picked messages to Client Components using useTranslations. react-i18next: your own middleware and [lng] segment, createInstance per request with resourcesToBackend loading locales/${lng}/${ns}.json and getT on the server, and a separate long-lived client instance using useTranslation with a backend that loads namespaces on demand.](/blog/inline/next-intl-vs-react-i18next-1.webp)
If you're adding internationalization to a React or Next.js app, you will hit the same fork in the road almost immediately: next-intl or react-i18next? Both are mature, actively maintained, and used in production by thousands of teams. They just make very different assumptions about where your app runs and who renders your text.
Use next-intl if your app is a Next.js App Router project. It was designed around Server Components, locale-aware routing, and ICU MessageFormat, so the common path needs very little glue code.
Use react-i18next if your app is not Next.js-only -- a Vite SPA, React Native, Remix, an Electron app, or a monorepo that shares translations across web and mobile -- or if your team already runs on i18next and its plugin ecosystem.
The rest of this guide explains why, with real setup code for both, a feature-by-feature comparison, the pitfalls that catch teams in production, and what a migration looks like.
Current releases and npm downloads, pulled from the npm registry on October 13, 2026. Download counts include installs pulled in by other packages, so read them as a measure of reach, not of how many apps use each library directly.
| next-intl | react-i18next + i18next | |
|---|---|---|
| Latest version | 4.14.9 | react-i18next 17.0.16 - i18next 26.4.4 |
| Weekly npm downloads | ~7.1M | ~17.9M (react-i18next) - ~24.1M (i18next) |
| Runs on | Next.js 12-16 only | Any React 16.8+ app, React Native, Node.js |
| Message format | ICU MessageFormat | i18next JSON (ICU via i18next-icu) |
| Server Components | Built in (getTranslations) |
Per-request i18next instance; hooks are client-only |
| Locale routing | Built in (defineRouting, proxy.ts) |
Bring your own |
react-i18next is the official React binding for i18next, a framework-agnostic internationalization core that has been around for over a decade. i18next itself knows nothing about React; react-i18next adds hooks (useTranslation), a Trans component for rich text, and a provider. Around that core sits a large ecosystem: language detectors, HTTP and filesystem backends, caching layers, an ICU plugin, and integrations with most translation management systems.
Because the core is framework-agnostic, the same i18next configuration and the same translation files can power a React web app, a React Native app, and a Node.js backend that sends localized emails.
next-intl is built specifically for Next.js. It supports both the Pages Router and the App Router, but its design centers on the App Router: translations work in async Server Components, Client Components, Server Actions, metadata, and route handlers, and it ships its own locale-aware routing, middleware, and navigation helpers. Messages use ICU MessageFormat out of the box, so plurals, selects, and number and date formatting live inside the translation string.
| Feature | next-intl | react-i18next |
|---|---|---|
| Framework scope | Next.js only | Any React renderer (web, React Native, Electron) |
| App Router & Server Components | First-class: getTranslations and useTranslations in server code |
Works, but hooks are client-only; server code needs a per-request i18next instance |
| Pages Router | Supported | Supported (commonly via next-i18next) |
| Message syntax | ICU MessageFormat, built in | i18next JSON format; ICU via the i18next-icu plugin |
| Plurals | {count, plural, one {...} other {...}} |
Suffixed keys: key_one, key_other |
| Routing & middleware | Built in: defineRouting, middleware, createNavigation |
Not included; you write your own |
| Type safety | Module augmentation of AppConfig |
Module augmentation of CustomTypeOptions |
| Namespaces & lazy loading | Nested message objects; load what you need in request.ts |
Namespaces are a core concept; lazy loading via backends |
| Language detection | Middleware: URL prefix, cookie, Accept-Language |
i18next-browser-languagedetector or custom detector |
| Plugin ecosystem | Small and focused | Extensive |
| Learning curve | Gentle for Next.js developers | Moderate: more configuration options and concepts |
A current next-intl (v4) App Router setup is split into a few small files. First, a single routing definition that the middleware and navigation helpers share:
// src/i18n/routing.ts
import { defineRouting } from "next-intl/routing";
export const routing = defineRouting({
locales: ["en", "fr", "de"],
defaultLocale: "en",
});
The middleware negotiates the locale and redirects or rewrites requests to the right prefix. (In Next.js 16 the middleware.ts convention was renamed to proxy.ts; the content is the same.)
// src/proxy.ts (src/middleware.ts on Next.js 15 and earlier)
import createMiddleware from "next-intl/middleware";
import { routing } from "./i18n/routing";
export default createMiddleware(routing);
export const config = {
matcher: "/((?!api|_next|_vercel|.*\\..*).*)",
};Request configuration tells next-intl which messages to load for the current request:
// src/i18n/request.ts
import { getRequestConfig } from "next-intl/server";
import { hasLocale } from "next-intl";
import { routing } from "./routing";
export default getRequestConfig(async ({ requestLocale }) => {
const requested = await requestLocale;
const locale = hasLocale(routing.locales, requested) ? requested : routing.defaultLocale;
return {
locale,
messages: (await import(`../../messages/${locale}.json`)).default,
};
});
Then the [locale] layout wraps the tree in NextIntlClientProvider so Client Components can read messages, and calls setRequestLocale so pages can be statically rendered:
// src/app/[locale]/layout.tsx
import { NextIntlClientProvider, hasLocale } from "next-intl";
import { setRequestLocale } from "next-intl/server";
import { notFound } from "next/navigation";
import { routing } from "@/i18n/routing";
export function generateStaticParams() {
return routing.locales.map((locale) => ({ locale }));
}
export default async function LocaleLayout({ children, params }) {
const { locale } = await params;
if (!hasLocale(routing.locales, locale)) notFound();
setRequestLocale(locale);
return (
<html lang={locale}>
<body>
<NextIntlClientProvider>{children}</NextIntlClientProvider>
</body>
</html>
);
}
Using translations looks the same everywhere. In an async Server Component you await getTranslations(); in a regular component -- server or client -- you call useTranslations():
// Server Component
import { getTranslations } from "next-intl/server";
export default async function Pricing() {
const t = await getTranslations("Pricing");
return <h1>{t("title")}</h1>;
}
// Client Component
"use client";
import { useTranslations } from "next-intl";
export function SeatCounter({ count }: { count: number }) {
const t = useTranslations("Pricing");
return <p>{t("seats", { count })}</p>;
}
Finally, createNavigation(routing) gives you locale-aware Link, redirect, usePathname, and useRouter wrappers, so you never hand-build /fr/pricing URLs. For the full walkthrough from an empty project, see our step-by-step guide to i18n in Next.js with next-intl.
react-i18next was designed before Server Components existed, and its hooks rely on React context, which only exists in Client Components. In the App Router that leaves two layers to configure.
Server side: the common pattern is to create a fresh i18next instance per request, so concurrent requests in different languages never share state. i18next-resources-to-backend lets you lazy-load JSON files per language and namespace with dynamic imports:
// src/i18n/server.ts
import { createInstance } from "i18next";
import resourcesToBackend from "i18next-resources-to-backend";
import { initReactI18next } from "react-i18next/initReactI18next";
export async function getT(locale: string, ns = "common") {
const i18n = createInstance();
await i18n
.use(initReactI18next)
.use(resourcesToBackend((lng: string, ns: string) =>
import(`../locales/${lng}/${ns}.json`)))
.init({ lng: locale, ns: [ns], defaultNS: ns, fallbackLng: "en" });
return i18n.getFixedT(locale, ns);
}
// In a Server Component
const t = await getT(locale, "pricing");
return <h1>{t("title")}</h1>;
Client side: a separate, long-lived i18next instance initialized in a client module, with useTranslation() in Client Components. You keep the client instance's language in sync with the locale segment of the URL, often by passing it down from the layout.
You also write locale routing yourself: a middleware that reads the cookie or Accept-Language header, redirects to a locale prefix, and a [lng] segment in your app directory. None of this is hard, but it is code you own and maintain. (If you are on the Pages Router, next-i18next wraps most of this for you; it does not target the App Router.)
This is the difference that matters most to translators, and it is easy to overlook. next-intl uses ICU MessageFormat:
{
"Pricing": {
"seats": "{count, plural, =0 {No seats} one {# seat} other {# seats}}"
}
}i18next uses its own JSON format, where interpolation uses double braces and plurals are separate keys with CLDR category suffixes:
{
"seats_zero": "No seats",
"seats_one": "{{count}} seat",
"seats_other": "{{count}} seats"
}
Both handle languages with complex plural rules correctly, because both resolve the category with Intl.PluralRules. The i18next format is easier to read for simple strings; ICU keeps the whole sentence in one key, which translators and translation platforms generally handle better for gender and nested selects. If you want ICU with i18next, add the i18next-icu plugin -- but then you are using the ICU format, not the i18next one, so pick one per project. Our ICU MessageFormat guide covers plural and select syntax in depth.
Both libraries can type-check your translation keys, and both do it the same way: TypeScript module augmentation pointing at your source-language JSON file. Neither generates code.
// next-intl: global.d.ts
import { routing } from "@/i18n/routing";
import messages from "./messages/en.json";
declare module "next-intl" {
interface AppConfig {
Locale: (typeof routing.locales)[number];
Messages: typeof messages;
}
}
// react-i18next: i18next.d.ts
import common from "./locales/en/common.json";
declare module "i18next" {
interface CustomTypeOptions {
defaultNS: "common";
resources: { common: typeof common };
}
}
With either setup, a typo like t("pricng.title") becomes a compile error. next-intl can additionally type ICU arguments in recent versions, so a missing count is caught as well.
Avoid picking either library based on a headline bundle number; what dominates in practice is how many messages you ship to the browser, not the size of the runtime.
With next-intl, text rendered in Server Components is resolved on the server and arrives as HTML. The message catalog itself does not need to be sent at all for those components. For Client Components, NextIntlClientProvider passes messages down; on large apps you can pass only the namespaces a subtree needs (for example with pick(messages, ["Pricing"])) instead of the entire file.
With react-i18next, server-rendered text works the same way when you use a per-request instance. Client Components need the resources loaded into the client instance, and the ecosystem's answer is namespaces plus a backend (HTTP or dynamic import) that loads pricing.json only when a component asks for the pricing namespace.
Both approaches can produce lean pages. next-intl makes the lean path the default in the App Router; react-i18next makes it a configuration choice.
Choose next-intl if:
Choose react-i18next if:
A useful tiebreaker: whoever owns the most code that renders text wins. If 90% of your UI lives in a Next.js app, use next-intl there even if a small React Native app uses i18next -- sharing raw JSON between two formats is easier than fighting the wrong library in your main app.
Teams moving an existing Next.js app to the App Router often make this switch. The work splits into three parts:
request.ts), turn {{name}} into {name}, and collapse key_one/key_other pairs into a single ICU plural. Script this; do not do it by hand.useTranslation("pricing") becomes useTranslations("Pricing"), and <Trans> becomes t.rich() with tag callbacks.defineRouting, createMiddleware, and createNavigation. Keep your existing URL structure so you do not lose rankings; see our hreflang and multilingual SEO guide before changing locale prefixes.Migrate route by route behind a feature branch, and run a pseudo-locale through the converted pages to catch any string that slipped through untranslated.
useTranslation() in a Server Component. With react-i18next, hooks need a Client Component. Use a per-request instance on the server instead of adding "use client" everywhere.setRequestLocale with next-intl. Without it, pages that use translations opt into dynamic rendering, and you lose static generation.en_US in file names, en-US in the URL, en in the HTML lang attribute. Pick BCP 47 tags once; our locale codes guide explains the rules.toFixed(2) strings.next-intl is built specifically for Next.js, with first-class App Router and Server Component support, built-in locale routing, and ICU MessageFormat. react-i18next is the React binding for i18next, a framework-agnostic library that also runs in React Native, Vite, Remix, and Node.js, with a large plugin ecosystem.
next-intl. Its getTranslations and useTranslations APIs work in Server Components, and it provides routing, middleware, and navigation helpers. react-i18next works in the App Router too, but its hooks are client-only, so server rendering requires creating an i18next instance per request.
Yes. react-i18next supports React Native, which makes it a strong choice for projects that share translations between web and mobile. next-intl only targets Next.js, so a React Native app would need a different library.
Yes. next-intl uses ICU MessageFormat natively for plurals, selects, and number and date formatting. i18next uses its own JSON format with suffixed plural keys such as key_one and key_other, and supports ICU only through the i18next-icu plugin.
Neither runtime is a meaningful bottleneck. What matters is how many messages reach the browser. next-intl renders Server Component text on the server by default, while react-i18next achieves similar results with per-request server instances and lazily loaded namespaces on the client.
next-intl is the specialist: if your product is a Next.js App Router app, it gives you Server Component translations, routing, and ICU with the least code. react-i18next is the generalist: if your translations need to work across React Native, other frameworks, or a backend, its framework-agnostic core and ecosystem are hard to beat. Pick based on where most of your text renders, keep your message files in one format, and type your keys either way. If you are still deciding how to structure those files, start with our explanation of JSON translation files.
Whichever library you choose, the translation files still have to stay in sync as your source strings change. Babelize detects new and changed keys and generates translations for every locale in your repository, with guides for both the Next.js and React SDKs.
--- - [All articles](https://www.babelize.co/blogs)