Next.js i18n in the App Router is done with locale-based routing, a library such as next-intl or react-i18next, and JSON message files for every language. You detect the user's locale in middleware, load the matching messages on the server, and serve each language on its own URL such as /en and /de. Add hreflang tags so search engines show the right version to each audience.
This guide walks through a clean Next.js internationalization setup, compares the common libraries, and shows how to keep your translation files manageable as the project grows.
How Next.js Internationalization Works
The built-in i18n routing config from the Pages Router does not apply to the App Router. In modern Next.js you build internationalization yourself, using a dynamic [locale] route segment plus middleware that picks the language. The official Next.js internationalization guide describes this pattern, and most teams add a library for message formatting, plurals and dates. If you are new to the vocabulary, start with internationalization vs localization.
Choose an i18n Library for Next.js
| Library | Strengths | Consider when |
|---|---|---|
| next-intl | Built for the App Router, type-safe messages, server component support, routing helpers | You want the most direct Next.js fit |
| react-i18next | Large ecosystem, many plugins, works across React projects | You share code with other React apps |
| react-intl (FormatJS) | Standard ICU message syntax, strong formatting | Your team already uses ICU messages |
| Lingui | Compile-time extraction, small bundles | You prefer extraction from source code |
| Custom dictionaries | No dependency and full control | Very small sites with few languages |
If you already use the i18next ecosystem, our guide to React i18n with react-i18next shows the setup that carries over to Next.js.
Step-by-Step Setup With the App Router
1. Create the locale route segment
Place your pages under app/[locale]/ so every language has its own path. Define the supported locales and the default in one config file, using BCP 47 codes such as en, de and pt-BR.
2. Add middleware for locale detection
Middleware reads the Accept-Language header or a saved cookie, then redirects or rewrites to the correct prefix. Keep the matcher narrow so images, API routes and static files are not affected.
3. Store messages in JSON files
Create one file per locale, for example messages/en.json and messages/de.json, with namespaced keys such as checkout.button.pay. Never build sentences by joining fragments. Use placeholders and ICU plural rules instead, as explained in our guide to ICU MessageFormat.
4. Load messages in server components
Fetch the messages for the current locale on the server and pass only what client components need. This keeps bundles small and avoids shipping every language to every user.
5. Add a language switcher
Use locale-aware links so switching language keeps the user on the same page and saves the choice in a cookie.
SEO for Multilingual Next.js Sites
- One URL per language. Use subfolders such as /de or domains, not a cookie alone, so crawlers can index every version.
- Hreflang tags. Declare every alternate version in the metadata, including an x-default.
- Translated metadata. Titles, descriptions and Open Graph data must be localized, not just the page body.
- Localized sitemap. Include every language URL.
- Translated slugs where it helps. Native-language URLs can improve click-through rates.
Our guide to SEO translation covers how to localize keywords instead of translating them word by word.
Common Next.js i18n Mistakes
- Hard-coded strings. Every visible string, including alt text and error messages, must live in a message file.
- Concatenated sentences. Word order differs between languages, so fragments break grammar.
- Ignoring text expansion. German and French strings are often longer, which can break buttons and navigation. Try pseudo-localization to catch this early.
- Wrong date and number formats. Use
IntlAPIs through your library rather than formatting by hand. - Missing fallbacks. A missing key should fall back to the default language, never display the raw key.
Keep Translation Files in Sync With Your Repository
Manual JSON editing works for two languages and falls apart at five. The usual workflow is to keep English as the source file, sync it with a translation platform, let translators work in a visual editor, and pull approved translations back through a pull request. This is called continuous localization, and it lets developers ship features while translations follow automatically. See also our guide on how to translate a JSON file without breaking keys.
A software localization platform with repository sync and branches handles this flow for you, so translators never touch code.
Frequently Asked Questions
Does Next.js have built-in i18n?
The App Router does not include automatic i18n routing. You implement locale routing with a dynamic segment and middleware, usually together with a library such as next-intl.
Which Next.js i18n library is best?
next-intl is the most common choice for App Router projects. react-i18next is a good fit if you share translations with other React apps.
How do I translate dynamic content from a CMS?
Store one entry per locale in the CMS, or use a translation platform connected to the CMS so new content is translated automatically.
Localize Your Next.js App With WordBeam
WordBeam syncs JSON files from GitHub or GitLab, pre-translates with AI, applies translation memory and glossary, and opens a pull request with approved text. Discover UI translations with visual context or start a free trial with 14 days and 10,000 words.