By Mehdi HassanWhat makes a good website language switcher?
A good website language switcher is findable, honest and respectful of choice. Findable means it sits in a predictable spot on every page. Honest means it labels languages the way speakers recognize them. Respectful means it never overrides what the visitor picked or the link they clicked.
The switcher is a small component, but it's the one place where a multilingual site either feels considerate or feels broken. When it fails, visitors who can't read the current page often can't read the instructions for fixing it either. It sits within the bigger structure and SEO decisions in our multilingual website guide, and it depends on each language having its own URL.
Where should the language selector go?
Put the language selector in the header, usually at the right end of the navigation (the left in right-to-left layouts), and repeat it in the footer. Those are the two places visitors scan when they're looking for it, and someone who can't read the page will look by position, not by reading labels.
- Header for any site where a meaningful share of visitors may arrive in the wrong language, such as from shared links or search results in another market.
- Footer as a reliable second location. Many visitors scroll to the bottom expecting settings there.
- Mobile menu near the top of the menu, not buried after every navigation item.
- Same spot on every page, including blog posts, legal pages and checkout steps.
A globe or language icon next to the current language's name helps people recognize the control without reading. The icon alone is ambiguous, because it can also mean region, currency or a world map, so pair it with text.
Why shouldn't you use flags in a language switcher?
Flags represent countries, and languages don't map to countries. A British flag for English is wrong for Americans, Australians and Indians; a Spanish flag for Spanish is wrong for most Spanish speakers; and some countries have several official languages. Flags make visitors feel excluded at the exact moment you're trying to welcome them.
Flags only make sense in a country selector, where the choice really is a country: shipping destination, local pricing, local legal terms. Many sites need both choices, which is why patterns like "Canada (Français)" exist. If you need both, show them as two separate things, or as combined labels, but don't let a flag stand in for a language.
How should languages be labeled in a language picker?
Label every language in its own name and script, because a person looking for their language recognizes its native name instantly. A German speaker scans for Deutsch, not German; a Japanese speaker scans for 日本語. The visitor's language is the one label that matters, and it should never be translated into the current page's language.
- Use the language's own name (endonym): English, Deutsch, Español, Français, 日本語, العربية.
- Add a regional variant only when you actually offer different versions, such as Português (Brasil) and Português (Portugal).
- Mark the current language clearly, with a check or a bold label, and don't link it to itself.
- Set the lang attribute on each option so screen readers pronounce it correctly, and add hreflang on the links.
- Order the list consistently, alphabetically by native name or by audience size, and keep the order identical on every page.
What should happen when someone switches language?
When someone switches language, they should land on the same page in the new language, keeping their place. Sending everyone back to the home page is the most common switcher failure, and it punishes the people who arrived deep in the site from search.
That means the switcher has to know each page's equivalent URL in every language, which is the same data you use for hreflang tags. Build both from one map. When a page doesn't exist in a language, either hide that option on that page or show it with a note that it'll go to the closest page, such as the section index. On a Next.js site, our guide to Next.js i18n shows how routes, the switcher and hreflang share one locale list.
How a well-behaved switcher handles the edge cases
For example, suppose a visitor reads an English blog post that only exists in English and German, on a site that also has French and Spanish.
The switcher shows all four languages. English is marked as current. Deutsch links straight to the German version of the post. Français and Español are shown in a quieter style with a short note that the post isn't translated, and link to the French and Spanish blog index pages instead.
When the visitor picks Deutsch, the choice is stored in a cookie. Next time they land on the English home page, a small banner offers the German version rather than redirecting them. If they follow a shared link to an English page, they see that English page, because a URL is an explicit choice.
Which language switcher examples get it right?
The strongest public language switcher examples share the same habits: text labels in native names, consistent placement, and a clear split between language and country when both matter. The patterns below are publicly visible on each site at the time of writing; sites change often, so check them yourself before copying a detail.
Site | Pattern | What it does well |
|---|---|---|
Wikipedia | List of languages by native name, per article | Links to the same article in each language and only lists languages where it exists |
Airbnb | Globe icon opening a language and region panel | Recognizable icon plus native names; separates language from currency |
Apple | Country or region link in the footer, to a full list page | Treats it as a country choice, with each country's language shown |
IKEA | Country chooser at the root domain | Asks once at the entry point rather than guessing, since ranges and prices differ by country |
Stripe | Locale selector in the footer | Combines country and language for a business where both affect the content |
The common thread is that each site matched the switcher to what actually changes. If only the language changes, a language list is enough. If prices, products or legal terms change by country, the choice is a country, and the language follows from it. Decide which you are before designing the component; our guide to multilingual web design covers the rest of the layout.
How do you make a language switcher accessible?
Make a language switcher accessible by building it as a real button that opens a list of real links, reachable and operable by keyboard, with a clear accessible name and correct language attributes. Many custom switchers fail here because they're built as styled divs or auto-navigating select menus.
- Use a button with an accessible name such as "Language: English", which announces both what it is and the current state.
- Make each option a link, so it can be opened in a new tab and works without JavaScript.
- Avoid select menus that navigate as soon as the value changes; keyboard users trigger them by accident while arrowing through options.
- Keep visible focus states and enough contrast, as covered in our guide to accessible web design.
- Close the menu with Escape and return focus to the button.
