How to Compare Screenshots of Indian Bank Websites on Mobile and Desktop

To compare Indian bank websites on mobile and desktop, capture the same public page in the same content and navigation state at a recorded phone-width viewport and desktop-width viewport. Compare content, legibility, reflow, navigation, and visible accessibility cues. Treat screenshots as evidence of appearance only: they cannot establish keyboard access, screen-reader behavior, image alternate text, or standards conformance.

This method gives you a reproducible visual comparison without implying that any particular bank performs well or poorly. Choose the bank sites and pages you want to assess, then record the conditions so another developer can repeat the captures.

1. Choose pages and capture conditions

Decide which banks to include and select the same public page, or a genuinely equivalent page, on each site. For example, compare account information pages with account information pages rather than comparing one bank’s home page with another bank’s product detail page.

1. Write down each page URL and the date of capture.
2. Choose a browser and keep it consistent across the comparison. Record the browser and version if you need others to reproduce the work closely.
3. Record the device context, CSS viewport width and height, and browser zoom. The CSS viewport is the layout width reported by the browser; it is not necessarily the physical pixel width of the screenshot.
4. Choose a consistent page state: same section or scroll position, same navigation state, and comparable dialogs or banners. Note any unavoidable difference, such as a site requiring a different route to reach equivalent content.
5. Capture one mobile-width and one desktop-width image for every selected page.

GIGW offers a useful responsive reflow checkpoint at 320 CSS pixels. It says content should be presentable at that width without loss of information or functionality, except where a two-dimensional layout is essential. This is a criterion for evaluation, not a finding about any bank’s current website. Read the GIGW accessibility guidance.

2. Capture both viewport sizes

Use a browser’s responsive device mode or set the viewport in browser automation. Keep the page state and zoom consistent, and wait for the page to settle before saving the image. Record the actual CSS dimensions used with each capture.

Browser automation with Playwright

The following runnable Node.js example captures a page at mobile and desktop viewport sizes. It uses the same URL and browser for both captures. Install Playwright and its Chromium browser first with npm install playwright and npx playwright install chromium, then save this as capture.mjs and run BANK_PAGE_URL='https://example.com/' node capture.mjs. Replace the example URL with a public bank page you are authorized to inspect.

import { chromium } from 'playwright';

const url = process.env.BANK_PAGE_URL;
if (!url) throw new Error('Set BANK_PAGE_URL to the page to capture');

const browser = await chromium.launch({ headless: true });
const cases = [
  { name: 'mobile', width: 320, height: 800 },
  { name: 'desktop', width: 1440, height: 1000 },
];

try {
  for (const viewport of cases) {
    const page = await browser.newPage({
      viewport: { width: viewport.width, height: viewport.height },
      deviceScaleFactor: 1,
    });
    await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
    await page.screenshot({ path: `${viewport.name}.png`, fullPage: true });
    console.log(`${viewport.name}: ${viewport.width}x${viewport.height} CSS px`);
    await page.close();
  }
} finally {
  await browser.close();
}

Some sites keep analytics or other requests active, so networkidle may never occur. If navigation times out, use waitUntil: 'domcontentloaded' and then wait for a page-specific selector or a short, documented delay. This makes the capture state more explicit than silently accepting whichever state happened to load.

Using browser developer tools

1. Open the chosen URL in the browser and open its responsive/device toolbar.
2. Set the mobile viewport width and height. Include 320 CSS pixels when using the GIGW reflow checkpoint; also capture any additional phone width relevant to your audience.
3. Set the desktop viewport dimensions and confirm browser zoom.
4. Bring the page to the agreed section and set navigation, menus, and dialogs to the agreed state.
5. Save each screenshot with a filename that identifies the bank, page, viewport, and date.

3. Compare the same criteria on every site

Use a shared checklist and report what the images actually show. The axes below synthesize responsive and banking-sector guidance; they are a practical comparison framework, not a published scoring system.

Criterion	What to inspect in both captures	Record as evidence
Content retained and legibility	Are the page title, key information, labels, and task-relevant links still present and readable? Does text become too small or wrap in a way that obscures meaning?	Name the visible content and describe clipping, truncation, or difficult wrapping. Avoid judging unseen content.
Responsive layout and reflow	Does content rearrange to fit the narrower viewport? Is there avoidable horizontal scrolling, overlap, or clipped content? Is a two-dimensional layout essential to the content?	Record viewport dimensions and the specific region that overflows or reflows. Apply the 320 CSS-pixel checkpoint where relevant.
Navigation and controls	Can a reader see the navigation entry point and task-relevant controls? Are collapsed menus or changed control placement intentional and understandable?	Note whether the menu was open or closed and describe visible control labels, placement, and apparent clipping.
Visible accessibility cues	Are headings and page titles visually clear? Are text-size or colour options visible? Is there a visible skip-to-main-content link where expected?	State only what the screenshots show. A hidden skip link may appear only on keyboard focus, so inspect the page directly.
Limits and follow-up	What cannot be determined from the images, including keyboard operation, screen-reader output, and image alternate text?	List the follow-up inspection needed instead of converting an unknown into a pass or fail.

The Department of Financial Services’ banking-sector guidance recommends accessibility for people including people with visual impairments and references IS 17802 and WCAG 2.1. Its recommendations include skip-to-main-content access, text-size and colour options, headings, appropriate page titles, and image alternatives. Consult the Department of Financial Services accessibility guidance before defining a broader evaluation.

4. Keep screenshot findings separate from accessibility conclusions

A screenshot can show visual presentation, such as whether a heading is clipped or navigation is visible. It cannot tell you whether a control works from the keyboard, whether its accessible name is useful, whether an image has alternate text, or what a screen reader announces. Those questions require page inspection and assistive-technology checks.

GIGW 3.0 describes WCAG 2.1 Level AA requirements and additional criteria addressing mobile users, low vision, and cognitive or learning disabilities. GIGW is guidance for Indian government websites; do not assume that every bank page automatically falls under it. See the official GIGW site. An Indian Bank page also documents screen-reader information, illustrating why assistive technology belongs in a fuller evaluation. See Indian Bank’s screen-reader page.

Use careful wording in findings: “The mobile screenshot shows the account link wrapping beneath the heading” is supported by the image. “The site conforms to WCAG” is not established by a screenshot comparison.

5. Make the comparison reproducible

Keep a capture log alongside the images. A simple CSV or spreadsheet can use these columns:

bank,page_url,capture_date,browser,device_context,viewport_width_css,viewport_height_css,zoom,content_state,image_file,notes

Use consistent filenames, for example bank-page-mobile-320x800-2026-10-04.png and bank-page-desktop-1440x1000-2026-10-04.png. Add a short note if a page redirected, presented a consent notice, or could not reach the chosen state. Do not silently compare different page content or different menu states.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. Its API can return a screenshot with one GET request; see the ScreenshotNeo API documentation. For a responsive comparison, make one request per viewport, setting the viewport options supported by the API:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -d viewport_width=320 \
  -d viewport_height=800 \
  -o mobile.webp

import requests

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

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
  viewport_width: '320',
  viewport_height: '800',
});
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('mobile.webp', new Uint8Array(await res.arrayBuffer()));

Replace the example URL with the selected public bank page and make a second request with desktop dimensions. Confirm parameter names and available options in the docs. 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 cost nothing, and response headers identify the page verdict and billing status. An MCP server exposes screenshot, page information, and PDF tools for AI agents. The free plan includes 1,000 shots per month without a card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

6. Troubleshoot capture and comparison problems

Problem	Likely cause	Fix
Mobile and desktop images show different content	The page changed between captures, the scroll position differed, or a different route or state was used.	Repeat captures close together, use the same URL and agreed state, and log redirects or dynamic content.
Screenshot width does not match the intended CSS viewport	Physical image pixels were mistaken for CSS viewport pixels, or device scale factor/zoom changed.	Set and record viewport width in CSS pixels and keep browser zoom and device scale factor fixed.
Automation waits indefinitely or times out	The page keeps network connections open, or the site loads slowly.	Use domcontentloaded plus an explicit selector or documented delay; choose a suitable timeout and report that condition.
Images or page sections are missing	Lazy-loaded content has not entered the viewport, or a page component has not rendered.	Scroll through the page before a full-page capture, wait for the relevant selector, and inspect whether the element is actually present.
A consent banner appears in one image only	Consent state, cookies, or regional behavior differs between runs.	Record the banner state. For a faithful comparison, use the same consent state; do not remove it if it is itself part of the experience being evaluated.
Horizontal overflow is hard to judge	The screenshot may crop the page or hide the source of overflow.	Inspect the page at the target viewport and identify the overflowing element; capture the full page and note any horizontal scrolling required.
A visual cue seems absent	Some links or controls appear only on keyboard focus or after interaction.	Inspect the live page with keyboard navigation and relevant assistive technology rather than treating absence from a static image as proof.

7. Performance, reliability, and cost

For a small comparison, capture one page and viewport at a time and keep the log with the outputs. For a larger set, parallel captures can reduce elapsed time, but avoid overwhelming bank sites; respect their access controls and any applicable usage terms. Dynamic pages may vary between runs, so record the capture time and state and repeat a capture if an unexplained difference affects the conclusion.

Browser automation gives you direct control over viewport, state, and capture behavior, but requires a browser runtime and maintenance when the environment changes. A screenshot API can reduce browser setup and can fit scripted or AI-agent workflows. ScreenshotNeo supports bulk capture of up to 100 URLs per call and caching with a chosen TTL; caching can reduce repeat work, but for a current visual comparison choose settings that ensure the returned capture reflects the intended page state. Only clean shots are billed under its stated billing model, while failed loads and cache hits are not billed. Its listed plans range from 1,000 free shots per month to paid tiers; check the current plan details before estimating a project budget.

FAQ

Should every comparison use exactly the same mobile width?

Use the same width across sites for a fair side-by-side comparison. A 320 CSS-pixel capture is a useful GIGW reflow checkpoint; you can add other widths to reflect the devices your evaluation targets.

Can screenshots prove that a bank website is accessible?

No. They support visual observations. Keyboard operation, screen-reader output, alternate text, and conformance need additional inspection and testing.

Does this method identify the best Indian bank website?

No ranking follows from the method alone. Choose a defined set of pages, capture them under recorded conditions, and report the observed evidence without generalizing beyond it.