Should a language switcher use flags?

Generally no. A flag represents a country, not a language, so it misleads for languages spoken in many countries (Spanish, English, Arabic) and for countries with several languages. W3C internationalization guidance advises against using country flags to represent languages. Use the language's own name, such as Deutsch or Español.

Where should the language selector go on a website?

Put it somewhere persistent and predictable, usually in the header or the footer, on every page. Because users who cannot read the current page still need to find it, it should be recognisable without relying on the current language, for example through its own-language label or a recognisable icon plus text.

Should I automatically redirect visitors to their browser language?

Be cautious. Google advises against automatically redirecting users between language versions based on a guess about their language, because it can stop users and search engines from reaching every version. Suggest a language with a dismissible banner instead, and always keep a visible manual switcher.

How should a language switcher behave when I change language?

It should take the visitor to the same content in the new language, not to the home page. If a translation of that page does not exist, send them to the nearest sensible parent page and say so, rather than silently dropping them on the homepage.

Language Switcher UX: Best Practices That Work

A good language switcher is easy to find on every page, names each language in that language's own script (Deutsch, Español, 日本語), avoids flags, takes the visitor to the equivalent page rather than the homepage, and remembers the choice without forcing a redirect. These behaviours are documented in W3C internationalization guidance and Google's multilingual-site advice, and they matter for search as well as usability.

Where should the language selector go?

Visitors who landed on a page in the wrong language need to find the control without being able to read the surrounding interface. That argues for a persistent, predictable location rather than something buried in a menu.

Common, defensible placements:

Header, near the top corner. Most visible, and consistent with what people see on other international sites. This is a convention rather than a documented requirement, so test it with your own audience.
Footer. Works as a secondary location, particularly for sites with many languages. Do not make it the only one on long pages.
Mobile navigation drawer, with a visible entry point. On small screens, a header icon-plus-label button that opens the list is usually enough, as long as it is reachable without scrolling deep into a menu.

Whatever you choose, put it in the same place on every template, including checkout, error pages and the 404 page. A switcher that disappears on some page types is a common cause of visitors being stranded.

How should languages be labelled?

Label each language in its own language and script. W3C's guidance on language selection says to write each link in the language it points to, so that readers can recognise their language even if they cannot read the current page. In practice:

Do	Avoid
Deutsch	German (on a page the visitor cannot read)
Español	Spanish
日本語	Japanese
العربية	Arabic

You may add the name in the current page's language as a secondary hint, but the own-language name should come first. The same W3C material suggests marking up each label with the right lang attribute, so assistive technology pronounces it correctly and browsers pick suitable fonts:

<nav aria-label="Language">
  <ul>
    <li><a href="/en/pricing/" lang="en" hreflang="en">English</a></li>
    <li><a href="/de/preise/" lang="de" hreflang="de">Deutsch</a></li>
    <li><a href="/ar/الأسعار/" lang="ar" hreflang="ar" dir="rtl">العربية</a></li>
  </ul>
</nav>

Right-to-left labels can need an explicit dir so punctuation and surrounding text order behave; see our guide to right-to-left languages. Also do not rely on abbreviations alone ("EN", "DE"); they are fine as a compact secondary label but are less recognisable than full names for many readers.

Why avoid flags for languages?

A flag identifies a country. Languages cross borders and countries have several languages. Spanish is not "the Spain flag" to a visitor from Mexico, English is not only the UK or US, and a Swiss flag cannot say which of four national languages you mean. W3C's guidance explicitly recommends against using country flags to represent translations, noting that flags suit regional variants rather than languages.

Flags are acceptable when you are genuinely selecting a country or market, for example a shop that changes currency and shipping per country. In that case, show the country name too, and keep the language choice separate. If you serve one language in several regions, describe the regions explicitly and keep the language label separate from the country.

How do you keep users on the equivalent page?

When someone switches language on /de/preise/, they expect to land on the English pricing page, not the English homepage. This requires a map from each page to its translations, which is the same data you need for hreflang annotations. If you already generate hreflang tags, reuse that mapping to build switcher links, so the two never drift apart.

Rules that hold up well:

Link to the translated URL directly. Use a normal <a href> to the target page so the switcher works without JavaScript and search engines can follow it. Google recommends adding hyperlinks to other language versions of a page.
Preserve context where sensible. Keep the same page, and where it is safe to do so, scroll position and non-sensitive state such as a selected product variant. Do not carry forward form data you cannot translate.
Have a fallback for untranslated pages. Link to the nearest translated parent (a category instead of a product), or disable that language entry for the page and say it is not available. Do not return a 404, and do not silently dump the visitor on the homepage.
Do not translate by swapping text in place on the same URL if you want those pages indexed; separate URLs per language are what Google's guidance recommends for multilingual sites. See client-side vs server-side translation and SEO.

Should the site remember the visitor's choice?

Yes, with care. W3C guidance suggests letting users save their language choice so later pages load in that language, overriding browser settings, and mentions a cookie or localStorage as mechanisms. Practical points:

Store only the language code, nothing identifying.
Treat the stored choice as a preference, not a redirect rule: if someone arrives from a search result or shared link to a specific language URL, show that URL's language. Respecting the URL they chose is more predictable than overriding it.
Check the privacy rules that apply to you before setting cookies, as consent requirements differ by jurisdiction.

Why not redirect automatically?

Automatic redirects based on browser language or IP address are fragile. Google advises avoiding automatically redirecting users from one language version to another based on assumed language, because it could prevent users and search engines from seeing all versions; it also notes that Googlebot usually crawls from the USA and sends requests without an Accept-Language header. W3C also cautions against guessing language from IP address.

A safer pattern is a suggestion: show a small, dismissible banner such as "Diese Seite gibt es auch auf Deutsch" on the page the visitor opened, and remember if they dismiss it. For the SEO side of this decision, read auto-redirect by language or location.

What about mobile and touch?

Make tap targets comfortably large and spaced. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels with some exceptions (see our accessibility article); larger is better for thumbs.
For two or three languages, show the options inline. For many, use a button that opens a full-screen or sheet list, ideally grouped and searchable, with the current language indicated.
Do not trigger navigation just by changing a <select> without warning; it surprises keyboard and screen-reader users. Prefer links, or a select plus an explicit "Go" button.
Keep the control visible on small screens without hiding it behind multiple menu levels.

How do you show the current language?

Mark the current language visually and programmatically: bold or check mark, and aria-current="true" on its link. Keep the list order stable across pages (alphabetical by own-language name, or by business priority) so muscle memory works. Avoid reordering the list by detected location.

Key takeaways

Put the switcher in a consistent, persistent location on every page type, including checkout and error pages.
Label languages in their own names and scripts, and mark them up with the correct lang attribute.
Do not use flags to represent languages; use them only for country or market choices, with text.
Switch to the equivalent page via real links, and define a clear fallback for untranslated pages.
Offer language suggestions rather than forced redirects, and remember explicit choices without overriding the URL the visitor requested.

Sources

W3C: Choosing a language for a multilingual site (language negotiation and selection) – own-language labels, no country flags, remembering the choice, avoiding IP guessing
W3C: Declaring language in HTML – marking up switcher labels with lang
Google Search Central: Managing multi-regional and multilingual sites – language-version links, avoiding automatic redirects, crawler behaviour
Google Search Central: Localized versions of your pages – separate URLs and reciprocal hreflang annotations
W3C WCAG 2.2: Target Size (Minimum) – 24 by 24 CSS pixel minimum target size