Internationalization and Localization Testing for Websites

Internationalization and localization testing checks whether a website works as intended across languages and locales—not just whether its words have been translated. Test language and direction metadata, scripts and layout, realistic local data and input, navigation, functional flows, and cultural assumptions. Automated checkers can flag technical issues, but browser testing and knowledgeable linguistic and cultural review are still needed.

Internationalization (i18n) is the design and development that makes a product adaptable to audiences that vary by culture, region, or language. Localization (l10n) adapts it for a specific locale. Translation is one part of localization. W3C recommends designing for internationalization early because retrofitting can require difficult, awkward, and costly re-engineering. See W3C’s explanation of localization and internationalization.

1. Define the locales and test scope

Start with the locales the product actually supports. Record the language, script, writing direction, and region for each. A locale is not simply a language label: two locales using the same language can differ in formats, conventions, and content expectations.

For each supported locale, identify the pages and journeys that matter: for example, landing pages, account creation, search, checkout, support, and error states. Include desktop and mobile layouts, authenticated and unauthenticated states, and content loaded after interaction. Use this scope to keep manual review and automation focused on real user paths.

Test area	Questions to answer
Language and direction	Are the page language and text direction identified correctly, including for language changes inside a page?
Rendering	Do representative scripts, long strings, fonts, and mixed-direction text render and behave correctly?
Forms and data	Can users enter and review locally appropriate names, addresses, dates, phone numbers, and other data?
Navigation and content	Can users find the localized experience, and are examples and imagery appropriate for the target locale?
Behavior and quality	Do complete journeys work, and have language and cultural choices received suitable human review?

2. Check language, direction, and encoding

Set the document language accurately and mark content in a different language where appropriate. Check the rendered page as well as source markup.
Check direction for right-to-left (RTL) pages and for embedded runs containing another direction, such as a Latin product code inside Arabic text. Verify punctuation, numbers, links, and controls in context.
Use UTF-8 and declare the encoding appropriately. Check that characters survive a round trip through page rendering, form submission, storage, and later display.
Test language switching and localized URLs. Confirm that the selected locale persists where intended and that direct links open the expected language.

W3C’s short internationalization review checklist and Internationalization Quick Tips cover language, direction, encoding, forms, navigation, and other review areas.

3. Exercise scripts, typography, and layout

Use representative content from each locale, including long translated strings and the scripts the site supports. Look for clipping, overlap, unexpected truncation, awkward wrapping, and controls that no longer fit. Check narrow viewports as well as desktop layouts.

Verify that language-appropriate fonts are available and that glyphs render rather than appearing as missing-character boxes.
Check line breaking, justification, letter spacing, and shaping for the scripts in scope. Do not assume spacing rules for one script apply to another.
Test text selection, copying, and cursor movement around bidirectional text, numbers, and punctuation.
Review icons, alignment, and layout assumptions in RTL. A mirrored layout is not automatically correct; check the direction and meaning of each control.
Test content changes after loading, including error messages and validation text, since translated strings can change a component’s dimensions.

The W3C Internationalization Tests index offers exploratory test areas for line breaking, justification, letter spacing, cursive shaping, language-specific fonts, selection, and direction. Treat them as a test menu, not as a universal pass/fail certification.

4. Test forms and locale-sensitive data

Use realistic data for the target locale instead of assuming one country’s conventions. Test both entry and display: accepting a value is not enough if the site later misformats, rejects, truncates, or misinterprets it.

Names: Try different name lengths and structures, including names with multiple parts, diacritics, and scripts other than Latin. Check whether fields impose unnecessary assumptions.
Addresses: Test locally appropriate address components and ordering. Check whether required fields make sense for the locales supported.
Postal codes and phone numbers: Test the formats the product claims to accept, including expected spaces, punctuation, and prefixes.
Dates and times: Check display, entry, validation, and interpretation. Make ambiguous dates unambiguous in the interface, and verify time-zone behavior where relevant.
Other local data: Review number, currency, and other locale-sensitive formats used by the product. Confirm that formatting is consistent across summaries, forms, and confirmation messages.
Validation: Trigger required-field, invalid-input, and server-side errors in each locale. Verify that the message is localized and points to a field the user can find.

Use the W3C review checklist and Quick Tips as prompts for names, addresses, local formats, and input.

Make localized pages findable through visible navigation that users in the target locale can understand. Check language selectors, links, and fallback behavior.
Review examples, images, symbols, and assumptions in content. Translation can leave an example confusing or inappropriate even when each sentence is linguistically correct.
Check that links, labels, headings, and calls to action remain clear after localization and fit the relevant layout.
Ask people who understand the target locale to review wording and cultural context. A technical checker cannot determine whether a translation is accurate or culturally appropriate.

W3C discusses translatability and cultural bias in images and examples in its internationalization and localization guidance.

6. Combine automated checks with browser and human review

Run the W3C Internationalization Checker on representative pages. It reports international settings such as encoding, language, and text direction, examining markup and HTTP headers.
Use relevant cases from the W3C Internationalization Tests to explore rendering and text behavior.
Open the actual site in a browser for each target locale. Exercise navigation, forms, responsive layouts, and complete user journeys with realistic content.
Have a qualified reviewer assess language quality, terminology, and cultural fit. Record locale, page, browser state, steps, expected result, and actual result for each issue.
Retest fixes in the affected locale and check shared components in other locales for regressions.

The checker is a useful page-level diagnostic, not an assessment of translation quality or cultural appropriateness. W3C’s test resources are exploratory tests, not a complete quality process. Choose an approach by the coverage it offers: markup and headers, language and direction, rendering, local data and input, functional journeys, and human review.

7. Capture locale-specific pages for visual review

Screenshot comparisons can help reviewers discuss layout changes across locales and viewport sizes. A screenshot captures what rendered at a particular moment; it does not prove that form input, navigation, language metadata, or translation is correct. Record the locale, viewport, and page state alongside each capture. For RTL or dynamic pages, inspect the live page as well as the image.

For repeatable captures, you can use a browser automation setup to set the locale and viewport, open the target page, wait for the relevant content, and save a screenshot. Exact browser configuration depends on the automation library and application. A browser image also cannot verify response headers or whether a language attribute is semantically correct; inspect those separately.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request captures a URL as PNG, JPEG, WebP, or PDF. The example below saves a screenshot of a localized page; replace the URL with the page and locale you want to review. See the ScreenshotNeo API documentation for parameters and formats.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/fr/ -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/fr/"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.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);

ScreenshotNeo removes known cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers indicate the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Every feature is available on every plan.

Create a free ScreenshotNeo account and get 1,000 screenshots a month with no card.

Performance, reliability, and cost notes

Keep the test matrix purposeful. Test every supported locale on high-value flows, and add cases for locale-specific components and known risks. W3C’s sources do not prescribe a universal number of pages or test cases.
Separate visual and functional evidence. A screenshot can expose clipping or overlap, but it cannot establish that text is accurate, inputs are interpreted correctly, or navigation works. Retain browser and human checks.
Make captures repeatable. Use consistent URLs, locale state, viewport, and page readiness conditions when comparing images. Dynamic content can differ between captures.
Budget from actual usage. The W3C checker and test resources are free web resources. ScreenshotNeo offers 1,000 shots monthly on its free plan; paid tiers 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. These are screenshot service plan limits, not a substitute for budgeting human localization review.

Troubleshooting

Symptom	Likely cause	What to check or fix
Checker reports missing or unexpected language or direction	Page metadata is absent, inaccurate, or inconsistent with rendered content.	Inspect the markup and HTTP headers, correct the page language and direction, and mark language changes within the content where appropriate.
Characters appear corrupted or missing	Encoding declaration, data handling, or font coverage is wrong.	Confirm UTF-8 is used and declared, then trace the same text through submission, storage, and rendering. Check fonts for the required script.
RTL page looks partly reversed or misaligned	Direction may be applied inconsistently, or embedded text runs and controls may have different direction needs.	Test the page with mixed-direction content and inspect punctuation, numbers, fields, and controls in the browser. Correct direction at the appropriate content or component level.
Localized text overlaps or is cut off	Components assume source-language string lengths or a particular line layout.	Test longer strings and narrow viewports; allow wrapping or resizing and review fixed heights, truncation, and control spacing.
Users cannot enter a valid local address or name	Form structure or validation assumes one locale’s data conventions.	Test representative local examples, remove unsupported assumptions, and review both client-side and server-side validation.
Date is accepted but later shown as a different day	Parsing, display, or time-zone handling is inconsistent or ambiguous.	Trace the entered value through storage and display; make input unambiguous and verify intended time-zone behavior.
Automated report is clean but the page still feels wrong	A checker reports technical settings within its scope; it does not assess translation quality or cultural fit.	Review the actual page and journey in a browser, then ask a qualified locale reviewer to assess language and context.
Screenshot differs between runs	Page content or readiness varies, or the captures use different locale, viewport, or state.	Standardize those conditions, wait for the relevant content, and compare the same page state. Investigate dynamic content separately.

Frequently asked questions

How do I test an internationalized website?

Define supported locales, check language, direction, and encoding, then test representative scripts, layouts, forms, local formats, navigation, and complete browser journeys. Combine technical checks with linguistic and cultural review.

What should I test when localizing a website?

Test translated content plus its fit and behavior: metadata, direction, typography, realistic input, date and time interpretation, navigation, validation, imagery, examples, and user flows in the target locale.

How do I test right-to-left layout?

Open the actual RTL experience and test page direction, mixed-direction text, punctuation, numbers, form controls, alignment, and navigation. Use realistic content and inspect the result in a browser.

Is there a free website internationalization checker?

Yes. The W3C Internationalization Checker is a free online resource that reports settings including encoding, language, and direction. It does not replace browser, translation, or cultural review.

What’s the difference between internationalization and localization?

Internationalization prepares a product for adaptation across locales; localization adapts it to a specific locale’s language, cultural, and other requirements.