react-i18next: Hooks-Based Internationalization for React and React Native

What react-i18next Solves and Who Uses It

React apps built with create-react-app or similar tools often start with hardcoded strings scattered across components. Replacing those strings with locale-aware alternatives requires a translation layer that integrates cleanly with React's component model. react-i18next is that layer: it wraps the i18next internationalization framework in React-specific primitives so that the translation call site stays at the component level without touching the build pipeline.

The library targets React developers who need to support multiple languages. It also covers React Native applications running v0.59.0 or higher. Server-side rendering environments are supported through the wider i18next ecosystem, which has documented server-side support for Node.js, PHP, Ruby, and .NET, among others. The same mental model transfers from browser to server: learn the hooks API once and apply it in every environment.

Hooks First: How the react-i18next Binding Works

Starting at version 10, react-i18next switched its primary API to React hooks. The current master branch is the v10 and later code. The legacy v9 branch, which used higher-order components and render props, remains accessible under the npm tag react-i18next@legacy.

The central export is `useTranslation`, a hook that returns a `t` function. Calling `t('someKey')` looks up the key in the currently active namespace and language, relying on i18next's backend and language-detection machinery to resolve the string. react-i18next handles the binding: it listens to i18next's language-change events and triggers re-renders in any component that called `useTranslation`.

The package also exports `initReactI18next`, a plugin that registers the React binding with i18next. A subpath export `TransWithoutContext` is provided for server components or situations where a React context boundary cannot be assumed.

Installing react-i18next and the Before and After in Component Code

Install the package from npm:

npm install react-i18next

The README states that no webpack configuration changes are required. There is no Babel transpiler or custom loader needed; the package works in any environment that supports the chosen module format. Bundlers receive it through the `module` field pointing to the ES module build at `dist/es/index.js`, and CommonJS environments use `dist/commonjs/index.js`.

For legacy projects that cannot upgrade to the hooks API, the v9 branch remains available under the `legacy` tag on npm:

npm i react-i18next@legacy

To wire react-i18next into an existing i18next instance, the package exports `initReactI18next`, an i18next plugin. Passing it through `i18next.use(initReactI18next)` before calling `init` registers the React binding. From that point, any component can call `useTranslation` to receive the `t` function, which looks up keys against the configured i18next resources.

The README shows the transformation from hardcoded JSX to a translated component. Before adding react-i18next, component markup looks like:

<div>Just simple content</div>

After wrapping with react-i18next, the same element uses a translation key:

<div>{t('simpleContent')}</div>

For React Native, the README documents one additional constraint: the device must run react-native v0.59.0 or higher, which is the minimum version that supports hooks.

The Trans Component for JSX with Embedded Markup

Plain `t()` calls handle strings, but JSX that mixes translated text with React elements presents a problem. A sentence that contains a link, a counted noun with a component child, or a bold word mid-sentence cannot be flattened into a string without losing the element tree. The `Trans` component handles this case.

The README shows the following pattern:

<Trans i18nKey="userMessagesUnread" count={count}>
  Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>.
</Trans>

The `i18nKey` prop identifies the translation entry. The `count` prop drives plural form selection. Interpolated values use double-brace syntax. React elements within the Trans tree pass through untouched, and the translator sees a string with numbered placeholders that correspond to those elements.

Where react-i18next Falls Short

react-i18next is a binding layer. It has no language detection and no translation file loader of its own. Both must come from separate i18next plugins that you select and configure. A team starting from scratch must choose a backend plugin, a language-detection plugin, and optionally a caching layer before the first string can load. The library itself gives no guidance on which combinations to use.

React Native support depends on running react-native v0.59.0 or higher. Projects in corporate environments that maintain older react-native versions for backward compatibility cannot use the hooks API and are limited to the legacy v9 branch, which is maintained separately.

The absence of GitHub releases means there is no formal changelog link in the release tab; version history lives in the CHANGELOG.md file and in npm version tags.

react-i18next vs react-intl

react-intl, part of the FormatJS project, is the other well-established React internationalization library. Where react-intl ships its own message catalog format using ICU message syntax natively, react-i18next delegates all language management to i18next and accepts whatever backend plugin you attach. react-intl is self-contained; react-i18next is a connector into a broader ecosystem.

The practical difference appears in pluralization. react-intl handles ICU plural syntax inline within a single message string. react-i18next relies on i18next's built-in plural mechanism, which uses separate translation keys per plural form rather than an inline selector. ICU syntax keeps all plural variants in one string, which some translation tools prefer. The i18next key-per-form approach keeps translation files simpler for translators unfamiliar with ICU syntax.

For projects that have already configured i18next outside React, adding react-i18next costs little. For projects with no existing i18next setup, the choice between the two libraries is mainly a question of whether ICU message format is a requirement.

Maintenance, TypeScript Support, and Licensing

react-i18next is MIT licensed and available without cost. The repository tracks versioning through npm; version 17.0.15 is current on the master branch. The last commit to master was on 2026-09-21, confirming ongoing updates.

TypeScript type definitions ship in the package through both `.d.ts` and `.d.mts` files, supporting CommonJS and ES module consumers respectively. The repository includes TypeScript example projects under `example/react-typescript/` that illustrate typed usage. The package.json `exports` map exposes separate type entry points for `require` and `import` paths, which avoids the dual-package hazard in mixed environments.

The project has no external runtime dependencies beyond what i18next itself brings. The package.json shows `side-effects` is not declared, which means bundlers cannot mark it as tree-shakeable by default.

Editorial conclusion

Engineers building new React apps with multi-language requirements who already use i18next or who want a hook-based API will find react-i18next the direct choice. Applications on react-native older than v0.59.0 cannot use the hooks-based API and should pin to the legacy v9 branch. Before adopting, verify that the i18next backend plugins your project needs, such as file loading, language detection, or caching, are available and compatible with the version you target.

Frequently asked questions

Official sources

1. i18next/react-i18next on GitHub
2. Issues
3. License: MIT
4. Project website
5. README