Chrome Screenshot Captures the Wrong Language Version of a Website
Chrome screenshots capture the page as rendered; they do not choose its language. Use this checklist to find the cause, fix the page, and capture the intended version.
A Chrome screenshot captures the page that has already rendered. It does not choose the website’s language. To capture the intended version, open its localized URL or use the site’s language selector, confirm the visible page is correct, and then take the screenshot. Chrome’s preferred languages or translation settings may affect what you see, but no browser setting is guaranteed to override a site’s own language routing.
Keep four controls separate: the website’s language version, Chrome’s preferred languages, Chrome’s page translation, and the language of Chrome or DevTools menus. Changing one does not necessarily change the others.
1. Check the website language before capturing
- Inspect the address bar. Look for a language-specific path or subdomain, such as
/fr/, or a country-specific domain. Use the site’s documented localized URL if you know it. - Use the site’s language selector. Choose the intended language and note whether the address changes. A visible selector or direct localized URL is the clearest way to request a site version.
- Confirm the page itself. Check headings, navigation, and other visible text after the page finishes loading. Do not infer the rendered language from the URL alone.
- Capture only after it is correct. In Chrome DevTools, use the screenshot command for the visible viewport or the full-size screenshot command for the whole page.
Google recommends using distinct URLs for language versions and links that let users switch between them. It advises sites to avoid automatically redirecting visitors from one language version to another based on an inferred language preference. See Google’s multilingual and multi-regional site guidance.
2. Tell the four language controls apart
| Control | What it changes | What to check |
|---|---|---|
| Website language selector or localized URL | The site’s own language version, if it provides one | Whether the page and URL change after selecting a language |
| Chrome preferred languages | The language preferences Chrome can present to sites | Order and presence of languages in Chrome Settings → Languages |
| Chrome page translation | The translated text Chrome displays for the current page | Whether translation is active and which target language is selected |
| Chrome or DevTools interface language | Browser or developer-tool menus and labels | Whether the interface changed while the website content stayed the same |
Chrome’s browser interface language is a separate setting from website content. Chrome Help documents browser UI language selection on Windows; on Mac and Linux, Chrome uses the system’s default language. DevTools also has a locale preference for its own interface. Changing that locale does not select a site language.
3. Review Chrome language and translation settings
- Open Chrome Settings and go to Languages.
- Review the preferred-language list. Add the intended language if needed and move it higher in the list if it should be preferred.
- If Chrome translated the page unexpectedly, review the Google Translate settings and target language in the same section. You can also use Chrome’s translate control or the page’s right-click menu to request translation.
- Reload the site and check the actual rendered text before taking a new screenshot.
Preferred languages are hints a site may use; the site decides how to use them. Translation changes the displayed rendering, but it is not the same as opening the site’s own localized version. For current steps, see Chrome Help: Translate pages and change Chrome languages.
4. Diagnose saved preferences and language routing
If the site keeps returning to another language, use a private window as a diagnostic comparison. Open the same direct localized URL and select the same language there. If the result differs, saved site state may be involved, but that comparison alone does not prove cookies caused the behavior.
For a site you develop, inspect the navigation and document requests in DevTools Network. Check redirects, the final URL, response content, and any language-related request headers or application routing. Do not assume that Accept-Language alone explains the result: Chrome’s Accept-Language reduction limits language information exposed in requests and through navigator.languages. The server or application may also use saved preferences, account settings, geo signals, or its own fallback rules. See Chrome Enterprise guidance on Accept-Language reduction.
5. Capture the confirmed page in Chrome
Once the intended version is visibly rendered, capture it from DevTools. Device Mode supports a screenshot of the visible viewport and a full-size page screenshot. Open DevTools, enable Device Mode if you need a specific viewport, then open the DevTools command menu and choose the screenshot command you need. The full-size command captures beyond the current viewport; it still captures the language the page rendered.
DevTools’ language preference affects the DevTools interface locale and applies after DevTools is reloaded. It is not a website-language control. See Chrome DevTools: Capture a screenshot and DevTools preferences.
6. Troubleshooting common causes
| Symptom | Likely cause | What to do |
|---|---|---|
| Screenshot and page both show the wrong language | The site opened a different language URL or routed the visit to a fallback | Choose the site’s language selector or open its localized URL directly; inspect redirects and the final address. |
| The site changes language after you select one | The site may be applying a saved preference or routing rule | Compare the same URL in a private window, then inspect site state and redirect behavior. Treat the comparison as a clue, not proof of a cookie cause. |
| The page is in the right language, but Chrome changes the text | Chrome page translation is active or offered | Review Chrome Settings → Languages → Google Translate and the translation target; reload and verify the displayed page. |
| Chrome menus are in the wrong language | Browser UI language or system language differs | Review Chrome’s interface language options for your operating system. This does not necessarily affect site content. |
| DevTools menus are in the wrong language | DevTools locale differs from the desired interface locale | Change the DevTools Language preference and reload DevTools. This does not set the website language. |
| Changing language preferences has no effect | The website may ignore browser preferences, use other signals, or expose reduced language information | Use the site selector or localized URL, then inspect application routing if you maintain the site. |
| Full-page capture still has the wrong language | The screenshot command captured the page correctly, but the page itself rendered in the wrong language | Fix the URL, selection, translation, or routing first; then recapture. |
7. Make automated captures more reliable
- Request the localized URL directly where the site provides one; avoid relying on a browser preference to choose a version.
- Set the browser context’s preferred languages when your automation framework supports it, but verify the result because the site controls how it interprets those preferences.
- Wait for the language selector or a known localized page element, then assert visible text before saving the screenshot. A navigation-complete event alone does not guarantee the expected language has rendered.
- Record the final URL and a small language-specific check with each capture so that routing mistakes can be distinguished from screenshot failures.
- When testing translation, treat the translated rendering and the site’s native localized URL as separate test cases.
For a diagnosis, compare the direct localized URL with the site’s default entry URL under the same browser settings. This helps identify whether the discrepancy comes from routing or from a capture taken before the page reached its intended state.
8. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. A screenshot API captures the page the site serves, so first pass the intended localized URL and confirm that the site serves the desired language. One GET request returns an image or PDF; see the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com/fr -o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com/fr"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com/fr' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);
Replace the example localized path with the target site’s actual language URL. ScreenshotNeo accepts cookie and consent banners as a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots.
Sign up for 1,000 free screenshots a month, with no card required.
9. Performance, reliability, and cost notes
- Performance: Confirming the intended URL and rendered language before capture avoids spending time diagnosing a screenshot that faithfully recorded the wrong page. If a page changes language after load, wait for a language-specific element before capturing.
- Reliability: A screenshot tool records the rendered result; it cannot guarantee that a site’s language negotiation selected the desired version. Use a direct localized URL and verify the content. Chrome’s reduced language signals mean header-only assumptions can be unreliable.
- Cost: Chrome DevTools is built in. For API capture, ScreenshotNeo’s free tier is 1,000 shots monthly with no card; plans listed are Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. Only clean shots are billed.
FAQ
Does changing Chrome’s language force every website to use that language?
No. It changes browser preferences or interface settings depending on which control you use. The site decides how to use language signals; its own selector or localized URL is the direct request.
Does DevTools have a setting that changes the page language?
No. DevTools’ locale setting changes the DevTools interface. Set the website language through the site or its URL.
Can Chrome translate a page without changing its original language URL?
Yes. Chrome translation changes the displayed text, which is distinct from visiting the site’s native localized version.
Why does a full-page screenshot show the same wrong language?
Full-page capture changes how much of the rendered page is included. It does not select or translate the site language.


