How to Compare Screenshots of an Indian Government Portal Before and After an Update

To compare an Indian government portal before and after an update, capture the same page under matched conditions: use the same browser and version, viewport dimensions, zoom, language, and interaction state. Keep both original screenshots and record the capture date, environment, and build. Compare them side by side, with a semi-transparent overlay, or with a pixel-difference image. Review each changed region against the intended update, then repeat the check at other relevant screen sizes and browsers.

This workflow helps locate visual changes; it does not prove that a portal is compliant or accessible. Follow visual comparison with checks of keyboard use, assistive-technology output, semantics, and form behavior.

1. Define a repeatable comparison

A comparison is useful only when the two captures differ mainly because of the update. Before capturing, write down the conditions you will hold constant:

• Page and state: use the same URL, logged-in or logged-out state, form values, open menus, and scroll position. Record any interaction needed to reach the target state.
• Browser: use the same browser and version for the before and after captures. If cross-browser coverage matters, compare each browser against its own baseline.
• Viewport and scale: match viewport width and height, device scale factor, and page zoom. A browser window size is not always the same as its CSS viewport size.
• Language and content: use the same language and, where possible, stable data. Dates, rotating notices, service availability, and personalized content can change pixels without a layout update.
• Timing and loading: wait for fonts, images, and page content to settle. Note whether animations, carousels, or live data were active.
• Environment: record operating system, build or release identifier if known, capture date and time, and any relevant network or account conditions.

Save the original files unchanged. Give them names that encode the page and capture conditions, for example home-before-2026-10-04-chrome-1440x900.png and home-after-2026-10-11-chrome-1440x900.png. Keep a short note alongside them with the exact URL, browser version, viewport, language, interaction steps, and build.

2. Capture the before and after states

1. Capture the page before the update, or retrieve the approved baseline captured under known conditions.
2. After the update is available, open the same page in the same browser environment.
3. Reproduce the same state and wait for the page to finish loading. Avoid capturing while a banner, animation, or asynchronous content is still changing unless that state is what you intend to review.
4. Capture at the same viewport and save the original image with its metadata.
5. Repeat at each screen size and browser that matters to the service. Government guidance recommends testing across browsers, browser versions, operating systems, connection speeds, resolutions, and devices.

For automated browser testing, Playwright supports screenshot snapshots and comparison with reference snapshots. Its documentation explains how to capture and compare snapshots, and how to update a reference when a change is intentional: Playwright visual comparisons. Treat baseline updates as review decisions: inspect the change first, then update the reference if it matches the intended result.

3. Compare the images and inspect changed regions

There are three practical ways to locate differences:

• Side by side: useful for understanding page structure and overall flow. Switch between images or place them next to each other at the same displayed scale.
• Semi-transparent overlay: align the images and blend them. Misaligned edges, text, and controls become visible as doubled outlines. This works best when the screenshots have identical dimensions.
• Pixel-difference image: calculate differences between corresponding pixels and display changed areas. This quickly surfaces shifts and missing elements, but can also flag antialiasing, font rendering, dynamic content, or tiny color changes.

Before interpreting a difference image, confirm that both source files have the same dimensions and are aligned. If dimensions differ, check whether the viewport or capture scaling changed; do not resize one image casually to make it fit, because that can hide layout errors.

1. Scan the whole page for major shifts, missing sections, unexpected blank areas, or content that is clipped.
2. Inspect changed regions at full size. Check the government identity and ownership, header, navigation, page title, service entry points, forms, buttons, alerts, dates, downloadable materials, and footer.
3. For each difference, decide whether it is expected, a visual regression, or an inconclusive change caused by dynamic content or capture conditions.
4. Record the finding with a crop or annotated comparison, the page and viewport, and a concise description of expected versus observed behavior.
5. After a fix, capture again under the same conditions and rerun the comparison. Preserve the original baseline and document any approved baseline change.

4. Review the portal in its government-service context

The Guidelines for Indian Government Websites and Apps (GIGW) apply to government websites and applications at central, state, district, and local levels. Their stated objectives include usability, user-centricity, and universal accessibility. The official guidance says, “These guidelines have been framed with the objective to make the government websites/apps conform to the essential prerequisites of the UUU trilogy of usability, user-centricity and universal accessibility.” See the official GIGW resources and its scope and objectives.

During visual review, check whether the update preserves clear government identity and ownership, key content, navigation, dates, downloadable materials, and service entry points. Verify that the layout remains usable at the tested screen sizes. The GIGW conformity matrix includes a check that the homepage displays its last-updated or reviewed date; see the GIGW conformity matrix.

GIGW 3.0 is based on international standards including ISO 23026 and WCAG 2.1, as well as the Rights of Persons with Disabilities Act, 2016 and the Information Technology Act, 2000. The official guidelines include recommendations for browser and device testing. Use the accessibility guidance for checks such as text alternatives and contrast.

5. Do not treat a visual diff as an accessibility verdict

A screenshot shows rendered pixels. It cannot establish whether images have useful text alternatives, whether keyboard interactions work, whether markup is semantic, or whether a form behaves properly. Two pages can look identical while differing in screen-reader output or keyboard behavior; a pixel difference can also be harmless while the page remains accessible.

Pair screenshot review with suitable manual and automated accessibility checks. Test keyboard navigation and focus, inspect accessible names and text alternatives, check contrast with an appropriate method, and exercise forms and service flows. The GIGW accessibility guidance describes requirements beyond visual appearance, including non-text alternatives and minimum contrast ratios.

6. Automate repeat captures with Playwright

For a page your team can access in a browser, Playwright can create a reference screenshot and compare future captures against it. The example below is a runnable starting point for a public page. Install Playwright Test, save the code as tests/portal-visual.spec.js, and replace the URL and expected page state with the portal page you are authorized to review.

npm init playwright@latest
npx playwright install

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

test('portal home matches its reviewed visual baseline', async ({ page }) => {
  await page.setViewportSize({ width: 1440, height: 900 });
  await page.goto('https://example.gov.in/', { waitUntil: 'networkidle' });
  await expect(page).toHaveScreenshot('portal-home.png', {
    fullPage: true,
    animations: 'disabled',
  });
});

Run the test once to create the reference snapshot, review and retain that baseline, then run it again after the update:

npx playwright test tests/portal-visual.spec.js

Playwright reports screenshot mismatches against the stored reference. Use its snapshot-update option only after reviewing the new image and deciding that the visual change is intended; consult the official snapshot documentation for update behavior and configuration.

Make the automated capture stable

• Set a fixed viewport and keep the browser version consistent in the environment that creates and checks snapshots.
• Use deterministic test data and the same authentication and interaction state for each run.
• Disable or stabilize animations and avoid volatile regions such as current-time labels, rotating banners, and live counters where possible.
• Wait for a meaningful page condition. Network idle may not occur on pages with persistent requests; in that case, wait for a stable selector or an application-specific ready state.
• Capture full-page screenshots when content below the fold matters. Also test key smaller viewports separately rather than assuming a desktop baseline covers responsive behavior.
• Keep browser and operating-system changes out of a baseline update where possible. A rendering environment change can alter fonts and antialiasing across many pixels.

7. Choose a workflow that fits the review

Workflow	Best fit	Trade-off
Manual captures and side-by-side or overlay review	A one-off update or a small number of pages	Simple to start, but repeatability depends on carefully recording and reproducing conditions.
Local browser automation with screenshot snapshots	Pages and states that need repeat checks during development	Requires browser setup, baseline management, and control of dynamic content.
Screenshot API capture	Captures from scripts or services without managing a browser locally	Review API options, capture controls, and billing behavior against your needs.

Compare workflows on setup effort, repeatability of browser and viewport conditions, how easily they locate changed pixels, coverage of browsers and viewport sizes, and whether reviewers can approve intentional changes while preserving a baseline. This is a practical selection framework, not a tested ranking of third-party services.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. It can return a screenshot in PNG, JPEG, or WebP, or a PDF, from one GET request. The API has options for full-page capture, viewport and device presets, waiting for a selector or network idle, custom headers and cookies, and caching with a chosen TTL. See the ScreenshotNeo API documentation for the request options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.gov.in/ \
  -o portal.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.gov.in/"},
    timeout=90,
)
r.raise_for_status()
with open("portal.webp", "wb") as image:
    image.write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.gov.in/',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = Buffer.from(await res.arrayBuffer());
require('node:fs').writeFileSync('portal.webp', bytes);

Keep capture parameters matched between before and after runs and retain your own dated baselines for comparison. ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. The same features are available on every plan. These captures can help create consistent images, but you still need to compare them and review changes against your intended update.

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

9. Troubleshooting common comparison problems

Symptom	Likely cause	Fix
Most of the image appears different	Viewport, zoom, device scale factor, browser version, fonts, or operating system changed.	Match capture dimensions and rendering environment; compare browser versions separately when needed.
Text or controls look doubled in an overlay	The images are shifted or have different dimensions.	Check dimensions and align corresponding page edges before blending. Recapture if the viewport changed.
Differences appear on every run	Dynamic dates, rotating content, animation, live data, or asynchronous loading is unstable.	Stabilize test data and state, disable animations where appropriate, and wait for a stable page condition.
A full-page image has a large blank or clipped region	Lazy-loaded content may not have loaded, or the page was captured before it settled.	Scroll or wait for the content to load, then capture again. Check the page at the viewport where the issue occurs.
A pixel diff flags small text edges everywhere	Font rendering or antialiasing differs between environments.	Use a consistent browser, operating system, fonts, and device scale factor; review affected regions rather than treating every pixel as a defect.
A Playwright snapshot changes after a dependency update	The browser build or rendering environment may have changed along with the page.	Inspect the diff, pin or standardize the test environment where practical, and update the baseline only after review.
The page never reaches network idle	Persistent polling, analytics, or streaming connections keep network activity open.	Wait for a page-specific ready selector or stable state instead of relying on network idle.
The screenshot looks correct but users report an accessibility problem	Pixels do not show keyboard behavior, semantics, accessible names, or screen-reader output.	Run accessibility checks separately, including keyboard and assistive-technology review.

10. Performance, reliability, and cost

For a few pages, manual capture and review may be the quickest workflow. Automated snapshots reduce repeated setup, but their reliability depends on stable page state, capture conditions, and deliberate baseline review. Covering more pages, browsers, and screen sizes increases capture and review work; prioritize service entry points and layouts where a change would affect users, then expand coverage as needed.

Pixel comparisons can produce noisy results when rendering or content is dynamic. Keep original captures and metadata so a reviewer can tell whether a difference came from the update or the environment. Do not silently replace a baseline to make a failing comparison pass; record why an intentional visual change is accepted.

Cost depends on the workflow. Manual captures and local browser automation do not require a screenshot API, though automation uses compute and maintenance time. A hosted API may charge according to its plan and billing rules. For ScreenshotNeo, the stated plans are Free: 1,000 shots monthly at no charge; 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. Only clean shots are billed; its response includes X-Page-Verdict and X-Billed headers. Check the current product documentation before implementing billing assumptions in a production workflow.

11. FAQ

Should I compare the homepage only?

No. Include the pages and states users rely on, such as service entry points and important forms. The homepage is one useful check, and the GIGW conformity matrix specifically includes its last-updated or reviewed date.

Can one screenshot prove that a portal meets GIGW?

No. A screenshot can help review rendered appearance, but GIGW covers accessibility and other requirements that pixels alone cannot establish.

When should I update a visual baseline?

After reviewing the changed regions and confirming that the new appearance is intended. Keep the prior baseline and a record of the approval so future comparisons remain explainable.

Should I compare captures from different browsers against one another?

Usually compare each browser with a baseline from that same browser and environment. Cross-browser comparisons answer a different question and can show normal rendering differences as well as defects.