How to Test Hindi Website Layouts with Playwright Screenshots

Use Playwright Test visual assertions against a real Hindi-language fixture, wait for the page’s used fonts to finish loading, and compare screenshots in a consistent browser and operating-system environment. Include narrow and wide viewports, representative Devanagari content, and the mixed Hindi and Latin text your site actually uses. Hindi reads left to right: set the document language to Hindi, but do not set right-to-left direction just because the content is not English.

A screenshot baseline is a versioned visual expectation for a particular rendering environment. It can catch changed wrapping, clipping, overflow, spacing, or missing glyphs; it does not by itself prove that the page’s translation or font choice is correct. Assert content and font readiness separately from the image comparison.

1. Set up Playwright visual assertions

Use Playwright Test’s toHaveScreenshot() assertion. On its first run it creates a reference screenshot; subsequent runs compare the current rendering with that reference. Review and commit baselines, and update them only when a design change is intentional. See the Playwright visual comparisons guide.

Install Playwright Test in your project and install the browser binaries for the browser project you plan to run. A minimal TypeScript test can look like this:

import { test, expect } from '@playwright/test';

test('Hindi landing page layout', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('/hi');
  await page.evaluate(() => document.fonts.ready);
  await expect(page.getByRole('main')).toHaveScreenshot('hindi-mobile.png');
});

This assumes your Playwright configuration supplies a baseURL and the application serves a Hindi route at /hi. If it does not, navigate to the full local or test URL used by your project. Keep the first baseline run deliberate: inspect what it captured, check that the expected Hindi content is present, and commit the reviewed reference with the test.

2. Build a representative Hindi fixture

A useful fixture should exercise the layout cases your site supports, rather than relying on a short placeholder. Include actual Hindi headings and body text, button labels, numerals, punctuation, long words or strings used by the product, and Latin-script names if the interface mixes scripts. Use the project’s own content where possible, especially text that has previously wrapped poorly.

Set language metadata on the document. For a Hindi page, use lang="hi" on the root element. Language metadata helps browsers and assistive technology interpret the language; text direction is a separate concern. Hindi uses left-to-right horizontal flow, so do not add dir="rtl" unless a particular embedded passage genuinely requires it. CSS writing modes are another separate control for vertical or other text flow. See MDN’s guides to the lang attribute, the dir attribute, and CSS writing modes.

<!doctype html>
<html lang="hi">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>हिंदी पृष्ठ</title>
  </head>
  <body>
    <main>
      <h1>अपनी वेबसाइट की जाँच करें</h1>
      <p>यह परिचय मोबाइल और डेस्कटॉप पर पंक्ति-विन्यास, रिक्त स्थान और अक्षरों की जाँच के लिए है।</p>
      <button>अभी शुरू करें</button>
      <p>Mixed script example: ProductName 2026 — हिंदी सहायता</p>
    </main>
  </body>
</html>

Use a font stack that includes a web font whose Devanagari coverage you have verified, followed by sensible fallback families. Do not assume a font supports the glyphs you need based on its name: verify coverage and licensing at that font’s authoritative source before selecting it. CSS font stacks choose the first usable font, so a machine that lacks the intended font can render different glyph shapes and metrics. MDN explains web fonts and fallback stacks.

3. Wait for fonts before capturing

If the page depends on web fonts, wait for the browser’s font loading and resulting layout work before taking the screenshot:

await page.evaluate(() => document.fonts.ready);

document.fonts.ready resolves when the fonts used by the document have finished loading and related layout operations are complete. This reduces captures taken while fallback glyphs are still visible. See MDN’s Document.fonts reference.

Do not treat document.fonts.check() alone as proof that a named font was actually used or is installed. It is not designed to verify a specific font’s availability. To establish that the intended face is applied, check the site’s styles and loading path, and make sure your fixture includes the characters whose coverage matters. See MDN’s FontFaceSet.check reference.

4. Choose viewports that reveal Hindi layout failures

There is no universal viewport set for Hindi screenshot tests. Select widths that match your application’s supported mobile, tablet, and desktop layouts, including the breakpoints where columns, navigation, or buttons change. The sample width of 390 pixels is only an example; use dimensions that correspond to your design requirements.

At narrow widths, look for clipped matras or other glyph parts, unexpected line breaks, horizontal overflow, crowded button labels, and text colliding with adjacent controls.
At wider widths, look for changed line lengths, alignment, spacing, and content that no longer matches its container.
Use long but realistic Hindi strings and narrow containers to exercise wrapping. Include mixed-script content if it occurs in production.
Capture a stable page region such as main when the test concerns that region, or capture the full page when page-level layout is the requirement.

Keep the selected viewport and screenshot scope explicit in the test. If responsive behavior is important, add a separate assertion for each relevant layout width instead of assuming one screenshot represents all widths.

5. Keep screenshot comparisons reproducible

Generate and compare baselines with the same Playwright and browser versions, operating system or container image, and headless configuration where practical. Rendering can vary with host OS, browser version, settings, hardware, power state, and headless mode. Screenshots can also differ across browsers and platforms because font availability and rendering differ. Playwright recommends using the same environment for reference generation and comparison; see its visual comparisons guidance.

If you need several actual browser and operating-system targets, keep the comparison environments explicit and maintain appropriate baselines for each project. Do not compare a baseline from one platform to a run from another and interpret every pixel difference as a product regression.

Use Playwright locale and timezone emulation when the page formats dates, numbers, or chooses localized content based on those settings. Locale emulation does not translate the page, ensure Hindi strings are present, or prove that the intended font rendered. Keep those checks separate. See Playwright emulation.

6. Review diffs and handle dynamic content carefully

When an assertion fails, inspect both the current screenshot and the diff before changing the baseline or loosening comparison settings. Confirm that the failure is not caused by a missing font, a different browser environment, changed content, or a genuine wrapping or clipping regression.

For genuinely volatile areas, Playwright supports targeted masks and a custom stylesheet through stylePath. Scope them narrowly. Do not mask Hindi text or the layout region whose rendering the test is meant to verify. Options such as maxDiffPixels and threshold settings can allow rendering variation, but choose them only after examining real diffs; an overly permissive setting can conceal a layout change. The available screenshot assertion options are documented in the Playwright guide.

7. Troubleshoot common failures

Symptom	Likely cause	What to do
Hindi glyphs are missing or appear as boxes	The selected or fallback font lacks the required Devanagari glyphs, or the web font did not load.	Verify coverage for the actual fixture characters, check the font request and CSS stack, and wait for `document.fonts.ready` before capture.
Text wraps differently on a developer machine and in CI	The environments differ in operating system, browser version, font availability, settings, or headless configuration.	Pin and align the browser and execution environment where practical. Generate and compare baselines in the same environment.
The first screenshot has fallback metrics, later screenshots do not	The capture ran before used web fonts and layout finished loading.	Await `document.fonts.ready` after navigation and before the screenshot assertion.
A test passes but the page still shows the wrong language or font	A visual comparison only checks pixels against its reference; a baseline can preserve an existing mistake.	Assert the expected Hindi text and inspect the applied font and language metadata independently. Review newly created baselines before committing them.
Pixel diffs appear on every run around a changing region	Dynamic content such as an animation, timestamp, or rotating item changes between captures.	Stabilize the fixture if possible; otherwise mask only that volatile element or use a narrowly scoped screenshot stylesheet. Keep the text and layout under test visible.
A baseline update hides a real regression	The reference was updated without reviewing why the image changed.	Inspect the current image and diff, identify the intended design change, then update and commit the baseline deliberately.
Mobile text overflows but desktop passes	The test covers only a wide viewport or lacks long representative content.	Add the supported narrow viewport and realistic long Hindi strings; inspect wrapping, container sizing, and button dimensions.

8. Performance, reliability, and maintenance

Keep the visual suite focused on layouts that carry real risk: representative routes, meaningful breakpoint widths, and content that exercises script and wrapping behavior. Each additional browser, platform, route, or viewport adds captures and comparisons to maintain. Decide coverage from your supported audience and product requirements rather than treating every possible combination as mandatory.

Reliability comes primarily from controlling the rendering inputs: fixture content, font loading, browser and Playwright versions, OS/container, headless configuration, and dynamic regions. A baseline is not a universal rendering truth. It records an expected result under the conditions that produced it, and every intentional change still needs review.

For broader browser and real-device coverage, choose environments based on audience and requirements. MDN notes that platform and browser coverage can be complex and points to real-device checks and hosted testing as possible approaches; see MDN’s testing overview. Account for the effort of keeping platform-specific baselines reviewed. No single screenshot can establish how every user’s device will render the page.

Or skip the browser setup

If you need a rendered page image without maintaining a browser capture setup, ScreenshotNeo provides a website screenshot API and MCP server. The one-call API can return a screenshot 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 -o shot.webp

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

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are never billed. Responses include page-verdict and billing headers.
An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf.
The Free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

For repeatable Hindi regression tests, keep Playwright assertions and reviewed baselines in your test suite. For a quick capture or an agent workflow, sign up for 1,000 free screenshots a month with no card.

FAQ

Should I set `dir="rtl"` for Hindi?

No. Hindi uses left-to-right horizontal text flow. Set the correct language metadata and use direction settings only when the text direction actually calls for them.

Does locale emulation add Hindi translations?

No. It can affect locale-dependent behavior such as formatting, but your application must supply the Hindi content.

Does a passing screenshot assertion prove my font is correct?

No. It proves that the captured rendering matches its reference within the configured comparison policy. Check font loading and coverage, and review the baseline itself.

Should I use one baseline for every browser and operating system?

Only when the rendering environment is the same. If you support multiple targets whose rendering differs, maintain and review appropriate baselines for those targets.