How to Test a Gujarati Website Layout with Automated Screenshots

Use Playwright Test’s toHaveScreenshot() assertion to compare a Gujarati page against an approved screenshot baseline. Keep baseline and comparison runs in the same browser and operating system environment, and verify Gujarati shaping in the fonts and browsers your site actually supports. Screenshot comparison catches visual changes; it does not by itself prove that every Gujarati glyph is rendered correctly.

1. Choose representative Gujarati pages and states

Start with pages from your own site that exercise the layout you need to protect. Include Gujarati navigation, long headings, body text, and responsive layouts where those are important to your product. Choose real page states, such as a menu open or a consent banner visible, if they are part of the experience you want to test.

There is no universal Gujarati font or browser matrix established for every site. Use the font and browser combinations in your support commitments, and verify representative Gujarati text in each. A baseline only tells you whether a later capture looks different from that baseline in its capture environment.

2. Install and configure Playwright Test

The example below assumes a Node.js project. Install Playwright Test and its browser binaries using the official Playwright getting started guide:

npm init -y
npm install --save-dev @playwright/test
npx playwright install

Add a script to package.json:

{
  "scripts": {
    "test": "playwright test"
  }
}

Create tests/gujarati-layout.spec.js. Replace the example URL with a page from your project that contains representative Gujarati content:

const { test, expect } = require('@playwright/test');

test('Gujarati page layout matches its visual baseline', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000/gujarati-page', {
    waitUntil: 'networkidle',
  });

  await expect(page).toHaveScreenshot('gujarati-page.png', {
    fullPage: true,
    animations: 'disabled',
  });
});

Run the test:

npm test

On the first run, Playwright creates the reference screenshot. Review it to make sure the page loaded correctly, the intended Gujarati text is visible, and the capture environment is the one you want to preserve. Later runs compare the current screenshot against that reference. See the official Playwright visual comparisons guide and screenshot assertion API for current options and behavior.

3. Make captures stable and review differences

Playwright’s screenshot assertion waits for two consecutive screenshots to match before comparing the result to the expected image. That helps with pages that settle after navigation, but your test still needs to arrange a consistent page state.

• Use a fixed viewport and the same browser project for baseline generation and comparison.
• Wait for any project-specific data or page state that must be present before capture.
• Disable animations when motion is incidental to the layout you are checking.
• Use masks for genuinely variable regions, such as a timestamp, only when that region is outside the test’s purpose.
• Do not mask Gujarati copy, glyphs, or the layout whose rendering the test is meant to check.
• Choose full-page capture when you need to inspect content beyond the viewport; use viewport capture when the visible fold is the intended scope.

When a screenshot differs, inspect the diff and the current screenshot. Determine whether the change is an intended design or content update, a real regression, or an environment variation before updating the reference. To approve an intentional change, review it and then run:

npx playwright test --update-snapshots

Do not update a baseline just to make an unexplained diff disappear.

4. Match the baseline environment to the supported environment

Screenshot rendering can vary with the host operating system, browser and platform, version, settings, hardware, power source, and headless mode. Generate and compare baselines in a consistent environment; Playwright recommends using the same environment that generated the baseline. If your site supports multiple materially different browser or platform combinations, maintain and review separate snapshots for those combinations.

Set the matrix based on your actual support commitments and user needs. For each selected combination, check that the Gujarati font is available and that representative text shapes as expected. This is a project-specific verification step: the available sources do not establish a universal Gujarati font recommendation.

5. Run the checks in continuous integration

Run screenshot tests in the same controlled environment used to create their references. A different operating system, browser build, or headless configuration can produce differences even when your application code has not changed. Keep the browser version and project configuration stable with your CI setup, and treat a proposed snapshot update as a reviewed code change.

If multiple supported environments matter, give each one its own baseline set and make it clear which environment produced a diff. Keep Gujarati content in the test so the comparison continues to cover the script and layout rather than only surrounding components.

6. cURL, Python, and Node.js alternatives for captures

Playwright Test is the workflow in this guide because its screenshot assertion manages reference screenshots and comparisons. If you need a capture file for a manual review or another pipeline, these examples use the Playwright CLI to take a screenshot after starting your site locally:

npx playwright screenshot --full-page http://127.0.0.1:3000/gujarati-page gujarati-page.png

The following Python snippet invokes that CLI command. It requires Node.js, Playwright Test, and the Playwright browser binaries installed as above:

import subprocess

subprocess.run(
    [
        "npx", "playwright", "screenshot", "--full-page",
        "http://127.0.0.1:3000/gujarati-page", "gujarati-page.png",
    ],
    check=True,
)

From Node.js, use the Playwright library directly for a one-off capture. This writes an image but does not compare it to a baseline:

const { chromium } = require('@playwright/test');

(async () => {
  const browser = await chromium.launch();
  try {
    const page = await browser.newPage({ viewport: { width: 1280, height: 900 } });
    await page.goto('http://127.0.0.1:3000/gujarati-page', {
      waitUntil: 'networkidle',
    });
    await page.screenshot({ path: 'gujarati-page.png', fullPage: true });
  } finally {
    await browser.close();
  }
})();

A cURL request can fetch a screenshot from an HTTP screenshot API, but cURL alone does not establish or compare Playwright test baselines. For a hosted screenshot capture, see the alternative below.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a screenshot; its documentation describes the API and its options.

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}`);

Adapt the target URL to your Gujarati page. ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers identify the page verdict and whether the request was billed. Its 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.

Sign up for 1,000 free screenshots a month, with no card.

Troubleshooting

Symptom	Likely cause	What to do
A diff appears on every run	The capture environment or page state varies, or the page has dynamic content.	Use the same OS and browser setup as the baseline, arrange the intended state consistently, and mask only unrelated changing regions.
Gujarati text is missing or looks wrong	The required font may not be available in that environment, or the chosen browser/font combination may render differently.	Verify the site’s intended font is loaded and inspect representative Gujarati text in each supported environment. Keep separate baselines where environments differ.
The screenshot is blank or incomplete	The page may not have reached the expected state before capture, or a dependency may have failed to load.	Check the page in the same browser environment, wait for the project-specific content to appear, and inspect console or network failures before accepting a baseline.
First run creates snapshots but no pass/fail comparison	No approved baseline exists yet.	Review the generated image carefully, then commit it as the reference for later runs.
Snapshot update hides an unexplained regression	The reference was replaced without reviewing the visual change.	Restore the prior reference if needed, inspect the diff, and update only after confirming the change is intentional.
Tests pass locally but fail in CI	Local and CI rendering environments differ.	Generate and compare snapshots in the same controlled CI environment, with consistent browser versions and settings.
Animation creates inconsistent captures	Motion changes the captured pixels while the page is being sampled.	Use the screenshot assertion’s animation handling when animation is not part of the behavior under test.

Performance, reliability, and cost

Screenshot tests take browser time and store reference images, so keep the suite focused on representative pages and states that protect important layouts. Full-page captures cover more content but produce larger images and may take longer than viewport captures. Run the essential checks in CI and expand the browser/platform matrix only where your support commitments justify the extra runs and baselines.

Reliability depends on repeatable inputs: same browser and operating system environment, stable page state, and deliberate handling of animations and variable content. Snapshot comparison reports visual change, not its cause. A human review is still needed to decide whether the difference is an intentional update or a regression.

With a self-hosted Playwright workflow, account for the compute and maintenance needed to install and run browsers and retain snapshot files. ScreenshotNeo offers a hosted capture alternative with a free 1,000 shots per month and paid plans from $5 for 3,000; only clean shots are billed according to its stated billing rules. Use a screenshot API capture to inspect a page or produce an image, and use Playwright’s assertion workflow when you need maintained visual baselines and automated comparisons.

FAQ

Does a passing screenshot test prove Gujarati text is correct?

No. It proves the current capture matches its approved reference within the assertion’s comparison rules. Verify the intended font and Gujarati rendering in the supported environments when establishing and reviewing baselines.

Should every browser use the same baseline?

Use a baseline generated in the same environment as the comparison. If supported browser or platform renders differ, keep environment-specific snapshots.

When should I update a Gujarati page snapshot?

After reviewing the diff and confirming the visual change is intentional, such as an approved content or design update.