How to Test an Indian Bank Website’s Desktop and Mobile Layouts with Screenshots

To test an Indian bank website’s desktop and mobile layouts, capture the same public page in the same interaction state at documented viewport sizes, then inspect both the screenshots and how the controls behave. Include a narrow 320 CSS pixel check, a desktop size, and the mobile sizes relevant to the review. Record browser, version, operating system, zoom, orientation, network condition, and capture time so another reviewer can reproduce the result.

Use public pages or a bank-approved test environment. Do not sign in to a live customer account to create evidence, and keep credentials, account numbers, balances, personal details, OTPs, and transaction information out of screenshots. A screenshot review can document visible layout and selected interactions; it does not certify security or prove compatibility with every device.

1. Set a safe and useful scope

Start with pages that can be reviewed without customer data, such as the home page, product or information pages, help and contact pages, and branch or ATM locators. For formal work, ask the site owner for its supported browser and device matrix, test environment, and data-handling rules. Use an approved staging environment and synthetic test data if a workflow must be exercised.

GIGW covers quality, accessibility, and security guidance for websites, applications, and mobile apps. Its cybersecurity guidance calls for security audit and clearance before production hosting. Visual comparison is not a substitute for that audit. [GIGW guidelines] [GIGW cybersecurity guidance]

2. Choose viewports and test conditions

Capture at least one desktop viewport and mobile portrait. Add an intermediate or tablet width if the layout changes between them, and mobile landscape when it is within scope. Include a 320 CSS pixel wide check: GIGW describes responsive design without horizontal scrolling at a width equivalent to 320 CSS pixels. This is a useful checkpoint, not proof of compatibility at every width or on every device. GIGW also recommends testing across relevant browsers, versions, operating systems, connection speeds, and screen resolutions. [GIGW guidelines]

There is no universal browser and device matrix established here for every Indian bank. For a formal review, use the bank’s own supported configurations. Indian Bank’s February 6, 2026 procurement document is one example of a bank specifying browser and device compatibility, including mobile devices, and responsive UI testing across form factors and accessibility needs; it is not a requirement that applies to every bank. [Indian Bank procurement information]

Capture	Purpose
Desktop viewport	Review wide navigation, content width, alignment, and desktop-specific controls.
Mobile portrait	Review narrow content order, menus, touch targets, labels, and overflow.
320 CSS pixel width	Check the GIGW responsive-layout checkpoint for horizontal scrolling and clipping.
Intermediate or landscape, if relevant	Find breakpoint problems between the main desktop and phone layouts.
Physical phone, if available	Check actual browser and device behavior that emulation may not reproduce.

Keep zoom consistent, normally at 100%, and record it. Record whether consent banners or other overlays are present; their appearance can change both layout and what is visible. If the site changes by region, cookie state, or time, note that as well.

3. Capture repeatable screenshots

Choose a public page and write down its exact URL.
Set a browser, version, operating system, viewport in CSS pixels, zoom, and orientation. Record network conditions and date and time.
Open the page in a fresh, consistent state. Handle consent banners consistently across captures; record whether they are shown or dismissed.
Wait for the page to settle. For pages with lazy-loaded content, scroll through the page before taking a full-page capture, then return to the region you need to inspect.
Capture the same page and interaction state at each viewport. Take a viewport screenshot for detailed alignment and a full-page screenshot when the complete content flow matters.
Use descriptive filenames, for example home-desktop-chrome-win-1440x900-2026-10-04.png and home-mobile-chrome-android-390x844-2026-10-04.png. Keep the review notes alongside the files.

With browser responsive emulation, set the viewport dimensions in CSS pixels rather than relying only on a named device preset. Emulation is useful for repeatable layout checks, but it does not fully reproduce every physical device. A real phone can reveal differences in browser chrome, touch behavior, fonts, rendering, and network conditions. One handset still cannot establish coverage across all devices or supported configurations.

4. Compare layout and behavior

Align the same page region before comparing screenshots. A raw pixel-diff can help locate changes, but font rendering, antialiasing, dynamic content, timestamps, and rotating banners can produce harmless differences. Use the image as evidence, then verify the behavior in the browser.

Fit and flow: Look for horizontal scrolling, clipped content, overlapping elements, unexpected blank areas, and content that disappears at narrower widths.
Content order: Check that headings, explanations, warnings, and calls to action remain in a sensible order when columns stack.
Navigation: Open and close menus. Check that navigation remains reachable and that focus is visible when using a keyboard.
Controls: Check that buttons and links are visible, usable, and not covered by sticky bars or overlays. Try keyboard navigation as well as pointer or touch input.
Forms: Confirm that fields have visible labels, instructions remain associated with fields, and controls fit without clipping. Do not submit real customer details.
Text and accessibility: Increase text size where possible and check that content remains readable and usable. Use accessibility tools or assistive technology appropriate to the review scope.
Visual clarity: Check contrast and whether important content remains legible at the tested size.

Indian Ministry of Finance banking accessibility guidance addresses keyboard support, user-adjustable text size, alternate text, consistent navigation, and assistive technology. RBI’s October 11, 2024 notification advises payment system participants to review systems and devices for accessibility, while cautioning that changes should not compromise security. These sources inform what to inspect; a screenshot alone cannot verify assistive technology behavior or security. [Ministry of Finance, Department of Financial Services] [RBI notification RBI/2024-25/83]

5. Record findings so they can be reproduced

For each issue, record the location, expected behavior, observed behavior, browser and device configuration, and screenshot reference. Include the exact page state and steps to reach it. Separate visual observations from behavior findings, and state which browsers, devices, and viewports were not covered.

Field	Example
Page and state	Public home page, menu expanded
Environment	Browser and version, OS, viewport CSS pixels, zoom, orientation
Conditions	Capture date/time, network condition, consent state
Expected	Primary navigation remains reachable at mobile width
Observed	Menu button is visible but its open panel is clipped at the right edge
Evidence	Screenshot filename and, for behavior, reproduction steps
Limits	Browsers and device configurations not tested

Only retain and share evidence under the bank’s approved handling rules. If an authorized test flow contains sensitive-looking data, use approved synthetic data and redact before sharing. The cited research does not establish a screenshot-specific redaction standard, so follow the bank’s policy.

6. Capture screenshots in code with ScreenshotNeo

If you need repeatable screenshots from a script, ScreenshotNeo provides a website screenshot API and MCP server. The API accepts a URL and returns an image or PDF. For this review, capture public pages or approved test pages only. The API’s viewport parameters let you request consistent dimensions; see the ScreenshotNeo API documentation for parameter names and current request details.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://www.example-bank.in/ \
  -d width=1440 \
  -d height=900 \
  -o bank-desktop.webp

Python

import requests

params = {
    "access_key": "YOUR_API_KEY",
    "url": "https://www.example-bank.in/",
    "width": 390,
    "height": 844,
}
response = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params=params,
    timeout=90,
)
response.raise_for_status()
with open("bank-mobile.webp", "wb") as image_file:
    image_file.write(response.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://www.example-bank.in/',
  width: '390',
  height: '844',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('bank-mobile.webp', image));

Replace the example domain with the bank’s public site or an authorized test URL, and choose a viewport for each capture. Keep the access key out of source control and logs. ScreenshotNeo supports full-page capture, element capture by CSS selector, device presets and custom viewports, dark mode, retina scale, custom CSS and JavaScript, selector or delay waits, network-idle waits, request blocking, custom headers and cookies, and caching with a chosen TTL. Use only options that fit the approved scope; for public pages, avoid supplying authentication cookies or customer data.

Or skip the browser setup

ScreenshotNeo can capture the same public URL through one GET request. The screenshot API and its request options are documented at screenshotneo.com/docs.

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

Before capture, cookie banners are accepted and removed along with 60+ known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. These automated captures are useful for public pages and approved test environments, while the review scope and privacy rules still apply.

Troubleshooting

Problem	Likely cause	What to do
The two screenshots show different content	The page state, consent state, time, or dynamic content differs.	Repeat with the same URL, interaction state, consent handling, and capture conditions. Record time-dependent content.
A full-page screenshot is missing lower images	Images may load only after scrolling.	Scroll through the page before capture or use an approved capture wait strategy, then capture the full page.
Text wraps differently on a phone than in emulation	Device fonts, browser rendering, zoom, or viewport settings differ.	Record CSS viewport and zoom, compare browser and OS, and validate on a physical device when relevant.
A pixel-diff reports many changes with no obvious defect	Font antialiasing, dynamic content, or rendering variation can affect pixels.	Align the same region and inspect the actual page; treat the diff as a locator, not a verdict.
The mobile page seems to fit but controls cannot be used	A screenshot does not show keyboard focus, menu behavior, or touch interaction.	Exercise links, menus, buttons, and fields in the browser with keyboard and touch or pointer input.
The capture contains private-looking information	The page or test flow exposed sensitive content.	Stop capture and sharing, follow the bank’s data-handling policy, and use public pages or approved synthetic test data.
The API request fails or returns an unexpected result	The URL, key, network response, or requested options may be invalid.	Check the URL and access key, inspect the HTTP response and ScreenshotNeo verdict and billing headers, and consult the API documentation.

Performance, reliability, and cost

Keep a review efficient by capturing only the pages, states, and viewport sizes that answer a stated review question. Full-page captures take in more content but can be harder to compare; viewport captures make precise alignment easier. Dynamic pages may need a consistent wait condition and capture time. A real device check adds coverage for behavior emulation may miss, but it does not replace testing the rest of the supported matrix.

With a browser-based workflow, the main cost is reviewer time and access to the browsers or devices in scope. With ScreenshotNeo, only clean shots are billed: bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with verdict and billing information in response headers. Plans are Free at 1,000 shots monthly, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan. Do not interpret automated screenshot capture as certification or security testing.

FAQ

Does passing the 320 CSS pixel check mean the site is mobile compatible?

No. It is one responsive-layout checkpoint. Test the relevant browser, OS, viewport, and device configurations for the review.

No. Screenshots show rendered pixels. Exercise keyboard behavior and use accessibility tools or assistive technology appropriate to the scope.

Is browser emulation enough?

It is useful for repeatable viewport comparisons. Validate on a physical phone when the review needs real-device behavior, and report which devices remain untested.

Does a visual review replace a bank security audit?

No. GIGW cybersecurity guidance describes security audit and clearance separately; screenshot comparison is evidence about visible layout and selected interactions.

What should I do if the bank’s supported device list is unknown?

Ask the site owner for its supported browser and device matrix. If unavailable, document the configurations you selected and state the coverage gaps.