How to Test a Marathi Website’s Mobile Layout with Playwright Screenshots

Use a fixed mobile viewport and a Playwright browser context with the mr-IN locale, then capture both viewport and full-page screenshots. Inspect the rendered Marathi text for clipping, awkward wrapping, overlap, and horizontal overflow. Locale emulation sets browser language signals and locale-sensitive formatting; it does not translate a page or prove that every physical phone behaves the same way.

This guide uses Playwright Test with TypeScript. It shows how to configure a mobile project, capture repeatable evidence, add useful checks, diagnose common failures, and decide what screenshot evidence can and cannot tell you.

1. Set up a repeatable mobile test

Start with representative routes: a landing page, a page with a long Marathi heading, navigation, a form, and text-heavy content. Include widths on both sides of any breakpoints that matter to your design. These are practical test choices, not a prescribed Marathi checklist.

Install Playwright Test if it is not already part of the project:

npm init playwright@latest

Playwright device descriptors provide selected device settings such as viewport, screen, user agent, and touch properties. Choose a preset that matches the browser and platform behavior you want to emulate. You can override its viewport when your responsive design needs a particular width.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  projects: [
    {
      name: 'mobile-marathi',
      use: {
        ...devices['iPhone 13'],
        locale: 'mr-IN',
      },
    },
  ],
});

The preset is an example, not a universal recommendation. If you want a controlled width independent of a named device, set the viewport explicitly:

use: {
  viewport: { width: 390, height: 844 },
  locale: 'mr-IN',
}

Playwright documents device and locale emulation. Locale affects navigator.language, the Accept-Language request header, and locale-sensitive number and date formatting. The application must still provide Marathi content and choose it appropriately.

2. Capture viewport and full-page screenshots

A viewport screenshot answers whether the first visible screen fits. A full-page screenshot helps inspect content below the fold. Element screenshots are useful when a specific menu, card, or form needs closer review.

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

const routes = [
  { name: 'home', path: '/mr/' },
  { name: 'article', path: '/mr/sample-article/' },
];

test('Marathi pages fit mobile layouts', async ({ page }) => {
  for (const route of routes) {
    await page.goto(route.path);
    await expect(page.locator('body')).toBeVisible();

    await page.screenshot({
      path: `artifacts/${route.name}-viewport.png`,
    });
    await page.screenshot({
      path: `artifacts/${route.name}-full.png`,
      fullPage: true,
    });
  }
});

Create the artifacts directory before the run, or configure your scripts to do so. The URLs above assume your Playwright baseURL is configured; otherwise use absolute URLs. Playwright’s screenshot documentation covers viewport, element, and full-page capture.

For a focused element capture, locate the relevant region and call screenshot on it:

const menu = page.locator('nav');
await expect(menu).toBeVisible();
await menu.screenshot({ path: 'artifacts/marathi-menu.png' });

3. Make the test state consistent

Visual evidence is only useful for comparison when the page state is repeatable. Keep the browser engine, device settings, viewport, locale, route, content, and relevant application state consistent between runs. If a page loads data asynchronously, wait for a specific page condition rather than relying on an arbitrary pause.

await page.goto('/mr/products/');
await page.locator('[data-testid="product-list"]').waitFor();
await page.screenshot({ path: 'artifacts/products.png', fullPage: true });

When the application has a known stable readiness signal, assert it before capture. Avoid waiting for all network traffic to stop if the page intentionally maintains connections such as analytics or live updates; wait for the content that matters to the screenshot.

4. What to inspect in Marathi mobile screenshots

Clipped or overlapping Devanagari: Look at long headings, buttons, navigation items, labels, and text near container edges.
Unexpected wrapping: Check whether words or lines break in ways that push buttons, cards, or neighboring content out of place.
Horizontal overflow: Inspect whether the page extends beyond the viewport or requires sideways scrolling unexpectedly.
Obscured controls: Look for sticky headers, banners, or overlays covering fields and actions.
Missing content: Confirm that the Marathi route actually rendered the expected text rather than a fallback, blank state, or error page.
Below-the-fold layout: Use full-page captures for long articles and forms, while remembering that a tall full-page image can be harder to inspect at normal scale.

A screenshot is visual evidence, not an interaction test. Exercise menus, links, forms, and touch-oriented behavior with separate assertions. If physical-device behavior matters, include checks on actual target devices; browser emulation represents the configured context and does not claim to reproduce every device behavior.

5. Add layout checks and visual comparisons

Start with readable screenshots and a short set of meaningful assertions. For example, check that a page-level container does not exceed the viewport width:

test('Marathi page has no document-level horizontal overflow', async ({ page }) => {
  await page.goto('/mr/');
  const dimensions = await page.evaluate(() => ({
    documentWidth: document.documentElement.scrollWidth,
    viewportWidth: document.documentElement.clientWidth,
  }));
  expect(dimensions.documentWidth).toBeLessThanOrEqual(dimensions.viewportWidth);
});

This catches document-wide overflow, but it does not prove that every element is positioned correctly. Pair it with visual review and targeted checks for important headings, controls, or containers. You can also use Playwright’s screenshot assertions for visual regression workflows; keep the browser, fonts, viewport, content, and application state consistent so changes are interpretable.

For broader coverage, make separate projects for different supported widths or device presets. A single mobile width can miss a breakpoint transition. Choose sizes from your own supported layout matrix rather than assuming one width is best for all Marathi sites.

6. Troubleshooting

Symptom	Likely cause	Fix
The page is in another language	The route or application does not select Marathi from the configured locale.	Use the Marathi route or configure the app’s language selection. Locale emulation sends language signals; it does not translate content.
Screenshot is blank or incomplete	The page was captured before its important content finished rendering, or navigation failed.	Assert a meaningful selector or ready state before capture and inspect navigation errors.
Screenshot looks different between runs	Viewport, browser, content, fonts, data, animation, or timing changed.	Stabilize the browser context and page state; wait for the content that matters and disable or account for changing animations in your own test setup.
Named device settings do not match the intended target	The chosen descriptor represents a different platform or browser context.	Choose a suitable descriptor or set the viewport and other needed context properties explicitly. Validate important behavior on the actual target device.
Full-page capture is excessively tall	The route contains long or unbounded content.	Capture the viewport or a relevant element for focused review, and use full-page capture selectively for below-the-fold inspection.
Overflow assertion fails	An element extends the document past the viewport, or the app intentionally uses a wider region.	Inspect the saved screenshot and identify the overflowing element; distinguish intended horizontal scrollers from accidental page overflow.

7. Performance, reliability, and cost

Screenshot runs take longer as you add routes, browser projects, full-page captures, and visual comparisons. Keep a compact representative set for quick feedback and run broader page and device coverage where your workflow can accommodate it. Reuse a stable route list and readiness conditions so failures point to layout or application changes rather than inconsistent capture timing.

Playwright screenshots run in your configured browser environment. The result is useful for repeatable visual inspection under that configuration, while physical device checks remain relevant when actual hardware behavior is part of the requirement. The cited Playwright documentation does not publish a Marathi-specific pass/fail metric or guarantee physical-device equivalence.

For cost, account for the infrastructure where your browser tests run and the time spent maintaining routes, expected images, and test state. This workflow does not require a separate screenshot API: Playwright can save the screenshots directly. A hosted capture API is an option when you want screenshot capture without maintaining browser setup.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A single request captures a page as PNG, JPEG, WebP, or PDF. Here is the one-call version for the Marathi route:

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

See the ScreenshotNeo API documentation for request options. You can set viewport and other capture parameters there when you need a mobile-sized capture.

Cookie banners are accepted and removed before the shot, and known newsletter popups and chat widgets can be removed; each step can be turned off.
Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. Response headers say the page verdict and whether the request was billed.
An MCP server lets AI agents using Claude, Cursor, or another MCP client take screenshots, inspect page information, and capture PDFs.
The free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 screenshots.

FAQ

Does `mr-IN` translate the site into Marathi?

No. It sets browser locale signals and locale-sensitive formatting. Your application must provide and select Marathi content.

Is a full-page screenshot enough to verify mobile behavior?

No. It helps inspect visual layout across page content, but menus, links, forms, and touch interactions need behavior checks too.

Should every test use a named phone preset?

No. Use a descriptor when its emulated settings fit your target, or set the viewport and context values your test needs. Pick coverage from your supported browser matrix.

Can browser emulation replace physical-device checks?

It provides repeatable evidence for the configured browser context. Test physical devices when their specific rendering or interaction behavior matters.