How to Test a Hindi Website Layout with Playwright Screenshot Comparisons

Use Playwright Test’s toHaveScreenshot() to compare a Hindi page against a reviewed reference image. Build representative Devanagari content into the test, keep the browser, operating system, fonts, viewport, and capture settings consistent, and inspect diffs before updating snapshots. That combination can reveal broken glyph shaping, changed line wrapping, spacing shifts, clipping, and responsive layout regressions.

Playwright’s visual comparison guide warns that screenshots can differ across browsers and platforms because of rendering and fonts. Keep baselines tied to the environment that produced them; a baseline from one browser or operating system may not be suitable for another. Playwright: Visual comparisons

1. Choose Hindi cases that can expose layout bugs

A screenshot test only checks the content and layout it captures. Include representative text from your site, or fixtures chosen to exercise the cases your design needs to support:

Short and long headings, navigation items, paragraphs, buttons, and form labels that appear on the page.
Devanagari sequences with conjuncts and vowel marks used in your content.
Text near wrapping boundaries, where a small font or width change could add a line or cause overflow.
Components with alignment or spacing requirements, such as labels beside controls or text inside buttons.
Mobile and desktop layouts at widths relevant to your supported breakpoints.

These are practical test-design choices, not a prescribed fixture list. The W3C Internationalization Working Group’s Devanagari Script Resources points to resources on script layout and presentation, including glyph shaping, line layout, page layout, and forms. It is a Group Note Draft, which W3C describes as work in progress.

Do not test only a generic Latin-language page and assume that its screenshot covers Hindi behavior. Keep the Hindi text whose shaping and layout you need to validate visible in the captured region.

2. Make the capture environment repeatable

Before creating a baseline, settle the environment that will also run future comparisons:

Pin the Playwright version and browser version used by the project.
Run baseline creation and comparison in the same operating system and execution setup where possible.
Use the same viewport dimensions, headless mode, installed fonts, and browser settings for each run.
Wait for the page’s required fonts and content to load before taking the screenshot.
If you intentionally test several browsers or operating systems, keep a separate baseline for each environment that can render differently.

Playwright notes that host OS, browser, settings, hardware, power state, and headless mode can affect output. If a project supports several environments, use separate baselines only for environments it actually supports and needs to validate. Do not treat a difference between environments as a Hindi regression without checking the environment first.

3. Install Playwright Test and add a screenshot assertion

For a new project, install the test runner and its browser binaries:

npm init playwright@latest

Choose the options appropriate to the project when prompted. The following example assumes an application is served locally and its Playwright configuration sets baseURL to that application. Adapt the route and content to your site.

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

test('Hindi home page layout on mobile', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('/hi/');
  await expect(page).toHaveScreenshot('hindi-home-mobile.png');
});

Run the test once to create the reference screenshot, then run it again to compare against that reference:

npx playwright test

Playwright’s screenshot assertions run through the Playwright Test runner. The first run creates a reference image; subsequent runs compare new captures against it. The assertion waits for two consecutive screenshots to match before comparison, which helps avoid taking a screenshot while the page is still changing. See the official visual comparison guide and PageAssertions API for version-specific details.

4. Cover viewport and full-page layout deliberately

A viewport screenshot checks the visible screen at the chosen dimensions. Use it for the header, first-screen content, or a specific component. To check below-the-fold content and the entire page’s vertical arrangement, enable full-page capture:

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

test('Hindi article page layout', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('/hi/article/');
  await expect(page).toHaveScreenshot('hindi-article-mobile.png', {
    fullPage: true,
  });
});

Use separate tests for materially different supported widths, for example a narrow phone layout and a desktop layout. Choose widths based on your site’s breakpoints and user coverage; there is no universal Playwright viewport matrix. Distinct names make it easier to review what each image covers:

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

for (const viewport of [
  { name: 'mobile', width: 390, height: 844 },
  { name: 'desktop', width: 1440, height: 900 },
]) {
  test(`Hindi home page layout: ${viewport.name}`, async ({ page }) => {
    await page.setViewportSize({ width: viewport.width, height: viewport.height });
    await page.goto('/hi/');
    await expect(page).toHaveScreenshot(`hindi-home-${viewport.name}.png`);
  });
}

This loop checks two chosen viewports in one test file. A project can use Playwright projects to exercise different browser configurations as well, but create and review baselines for each supported rendering environment.

5. Reduce noise without hiding Hindi regressions

Playwright disables animations by default for screenshot assertions. For intentionally dynamic regions, mask only the parts whose changing contents are irrelevant to the test, such as a live timestamp. A mask that covers Hindi text, a text container, or a responsive component can conceal the very regression the test should catch.

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

test('Hindi page with a volatile timestamp', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('/hi/');
  await expect(page).toHaveScreenshot('hindi-home.png', {
    mask: [page.locator('[data-testid="live-timestamp"]')],
  });
});

For broader screenshot-only normalization, the assertion API supports a stylesheet through stylePath. Keep such rules narrow: hiding text, suppressing overflow, changing widths, or replacing fonts could make a broken layout appear stable. Check the current PageAssertions API for the options available in the Playwright version pinned by your project.

Use maxDiffPixels or maxDiffPixelRatio only after inspecting failed image diffs and deciding what variation is acceptable. A permissive threshold can allow real text or wrapping defects through. Do not use tolerance as a substitute for understanding why images differ.

6. Review and update reference screenshots

When a screenshot assertion fails, inspect the actual image, expected baseline, and diff. Determine whether the change is a defect, a rendering-environment mismatch, or an intentional design or content update. If the change is approved, update the snapshots deliberately:

npx playwright test --update-snapshots

Review the resulting images and commit approved baselines alongside the test change. Do not accept every changed image automatically: an update can replace the reference with a screenshot that contains broken shaping, clipped text, or incorrect wrapping.

7. Troubleshooting common failures

Symptom	Likely cause	What to do
Many unrelated pixels differ between runs	The browser, OS, fonts, headless mode, settings, or other capture conditions changed.	Compare environment details with the baseline run, restore the pinned setup, or maintain separate baselines for supported environments.
Hindi glyphs appear as boxes or have unexpected forms	The expected font may not be installed or loaded, or the page may be captured before its fonts are ready.	Check the page’s font loading and the test environment’s installed fonts. Keep the intended font and Hindi text visible in the screenshot.
Lines wrap differently from the reviewed baseline	Viewport width, font rendering, font availability, content, or CSS changed.	Confirm the environment and viewport first, then inspect the text container and computed layout before deciding whether the change is intentional.
The test fails while a page is still changing	Content or application state is not stable at capture time.	Make the test state deterministic and wait for the relevant page condition. Screenshot assertions also wait for consecutive matching captures, but that does not replace application-specific readiness.
A real overflow or clipping issue is missed	A mask, screenshot stylesheet, or high diff tolerance hides the affected text or region.	Narrow the mask or stylesheet and reduce tolerance after reviewing the diff. Keep the text and layout under test visible.
A snapshot is missing or newly created unexpectedly	The test is running in a different project, snapshot path, or environment, or the baseline has not been committed.	Check the test configuration and snapshot files in version control; create or update the baseline only in the intended environment and review it.
A full-page image is much taller than expected	The route contains long content or page length is part of the capture.	Use viewport capture if only the first screen is in scope, or keep full-page capture if below-the-fold layout is part of the requirement.

8. Performance, reliability, and maintenance

Screenshot comparisons add browser work and image review to a test run. Keep the suite focused on representative pages and widths that cover meaningful Hindi layout risks. Reuse stable fixtures, avoid unnecessary full-page images when viewport coverage answers the question, and keep the capture environment pinned so unrelated differences do not trigger repeated investigation.

Reliability depends on deterministic page state as well as stable rendering. Ensure the route, content, and relevant assets are ready before capture; isolate genuinely variable regions carefully; and review diffs in code review. A screenshot test is a visual regression check, not a guarantee that every string, browser, font, or viewport is correct. Choose coverage based on the application’s supported users and rendering environments.

Maintenance cost comes largely from reviewing and updating baselines when a real design or content change occurs. Keep updates intentional and tied to the change that justifies them. Avoid broad tolerances or masking rules that make the test pass by ignoring the Hindi layout it was created to protect.

Or skip the browser setup

If you need a screenshot without managing a local browser capture flow, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns an image or PDF. Its capture can accept cookie or consent banners and remove more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. An 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 a month with no card; paid plans start at $5 for 3,000 shots.

For a Hindi page, pass its URL as the target. This cURL example saves a WebP response:

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

See the ScreenshotNeo documentation for API details. Sign up for 1,000 free screenshots a month with no card.

FAQ

Does Playwright compare Hindi text semantically?

No. A screenshot assertion compares rendered pixels. Use it to catch visual changes, and use other assertions if the test must verify text content or application behavior.

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

Only if the project’s capture output is consistent across those environments. Playwright documents rendering and font differences across browsers and platforms, so separate baselines may be needed for supported environments.

Should every Hindi page use full-page screenshots?

No. Capture the viewport for screen-specific layout; use full-page capture when below-the-fold content and page length matter to the test.

How should I handle an intentional font change?

Review the resulting glyph shapes, wrapping, spacing, and responsive behavior, then update and commit the baseline if the rendered change is approved.