Detect the user's language and redirect to the right version

Read the browser language, normalize locale values and redirect safely to the correct language version without loops or a frustrating user experience.

How much do you know about JavaScript?

📘 Theory

What problem this redirect actually solves

Language detection is not a trick. It is a friction-reduction pattern for international sites.

Imagine a landing page with Spanish, English and French versions. If someone enters through the root path, sending them to the best-fitting version can save an unnecessary decision.

But the redirect should not fight the user. Once someone has chosen a language manually, that preference deserves more weight than browser defaults.

Input

The visitor arrives at `/` or another neutral entry point.

No language fixed yet
No stored preference yet

Decision

The app checks browser preference and actual support.

`navigator.languages`
supported locale map

Output

The app resolves a route or a fallback.

`/es/`
`/en/`
`/fr/`

Read the browser locale without over-assuming

`navigator.language` is useful, but `navigator.languages` often gives a better picture.

`navigator.language` gives the primary browser locale, such as `en-US` or `es-ES`. That is enough for simple cases but it does not tell you about secondary preferences.

`navigator.languages`, when available, returns an ordered list. That lets you try the strongest preference first and fall back to the next supported option.

Normalize the locale and map it to a real route

Browsers return regional variants, while your site often works with base language codes.

A site may support `es`, `en` and `fr`, while the browser returns `es-MX`, `en-US` or `fr-CA`. That is why normalization should usually reduce the locale to its base language code.

A single object of supported locales makes adding new languages much simpler than scattering conditionals throughout the code.

Redirect without loops or history frustration

The biggest bug is usually not detection. It is redirecting too aggressively.

Before redirecting, check whether you are already on the correct path. If you skip that step, the site may perform pointless redirects or feel unstable.

In this use case, `window.location.replace()` is often better than assigning `href`, because it avoids leaving a useless redirecting entry in the browser history.

1 What problem this redirect actually solves 2 Read the browser locale without over-assuming 3 Normalize the locale and map it to a real route 4 Redirect without loops or history frustration

🧭 Key visuals

Language detection and redirect flow

It summarizes the decision chain from saved preference to fallback route and final redirect.

Diagram of browser languages being normalized into a supported locale and a safe redirect

🧪 Learn by doing

Example Interactive demo: see which route your site would choose Simulate browser preferences and a saved language choice before any real redirect happens.

⌄

🏁 Challenges

Challenge Challenge: build `getLocaleRoute()` with a reliable fallback Create a function that receives a list of browser locales and returns the correct route according to supported languages.

⌄

🧰 Resources

Useful links

MDN: Navigator.language MDN: Navigator.languages MDN: Window.location MDN: Navigator.language MDN: Navigator.languages MDN: Window.location

Test

Check your knowledge with a test about JavaScript.

Test for JavaScript

Course resources 62

📘 Glossary 🎧 Audio 📄 PDFs 🖼️ Infographics 🎬 Videos 🔗 Links 🧠 Flashcards 🧩 Snippets

‹

Lesson 32

Browser persistence: `localStorage` and `sessionStorage`

Lesson 34

Async foundations: event loop, call stack and queues

›