How to Monitor Website Visual Changes Using ScreenshotMachine

To monitor website visual changes with ScreenshotMachine, capture the same URL on a schedule using fixed dimensions and page state, save each dated image, and compare it with a reviewed baseline. ScreenshotMachine provides the screenshot capture API; the reviewed documentation does not establish scheduled monitoring, retained visual history, automated image diffs, or alerts, so plan to supply those pieces with your own scheduler, storage, comparison step, and notification workflow. ScreenshotMachine documents a GET API with controls for dimensions, device, format, cache age, delay, cookies, headers, and selector-based capture. See the ScreenshotMachine API documentation. [c001]

1. Decide what counts as a change

Start with the pages and visual states that matter. For each check, define:

The exact URL, including relevant query parameters.
Whether to capture the viewport, a full page, a CSS-selected element, or a pixel crop.
The device and fixed width and height.
Any required cookies, language, or user-agent context.
What should trigger investigation: any pixel change, a threshold of changed pixels, or a reviewed difference in a critical region.

A screenshot comparison can report visual differences; it cannot decide by itself whether a difference is a defect. Rotating promotions, timestamps, personalized content, ads, and delayed widgets may change without indicating a regression. Exclude volatile regions where appropriate and have a person review meaningful or borderline diffs.

2. Capture a repeatable baseline

Use the same capture settings on every run. A baseline is the approved image that later captures will be compared against. Save it with enough metadata to reproduce the capture: URL, timestamp, viewport, format, device, delay, cache setting, and any cookie or header state. Keep a baseline version or commit reference so a later intentional redesign does not erase the record of what changed.

ScreenshotMachine documents these relevant options:

Option	Use	Documented details
`dimension`	Set width and height, or full-page height.	Width 100–1920 px; height 100–9999 px; `full` is available for full-page height.
`device`	Choose a device class.	`desktop`, `phone`, or `tablet`. The docs give typical examples of 1024×768, 480×800, and 800×1280 respectively.
`format`	Choose image output.	`jpg`, `png`, or `gif`.
`cacheLimit`	Control screenshot freshness.	0–14 days; `0` requests a fresh screenshot. Decimal values can represent shorter intervals.
`delay`	Wait for content or animation to settle.	0–10,000 ms.
`zoom`	Adjust capture zoom.	10–400%; the docs note optimization may ignore zoom for screenshots smaller than typical device dimensions.
`click`, `hide`	Dismiss or remove obstructing elements.	CSS selectors identify elements to click or hide before capture.
`cookies`, `accept-language`, `user-agent`	Reproduce a page state or request context.	Use consistently when the page varies by session, language, or client.
`selector`, `crop`	Limit capture scope.	Capture a DOM element or a pixel region rather than the whole page.

These are capture controls, not monitoring controls. Check ScreenshotMachine’s current documentation for exact parameter syntax and accepted values before deploying a request. URL-encode the target URL and any values containing special characters. [c001]

3. Make a capture with ScreenshotMachine

The following runnable examples request a 1280×900 PNG from https://example.com, force a fresh capture, and wait one second. Replace the placeholder key and target URL. Keep the API key on a server or in a secret store; do not embed a reusable key in public browser code. The ScreenshotMachine documentation also describes a URL hash approach for calls made from public HTML; follow its current guidance if that applies. [c001]

cURL

export SCREENSHOTMACHINE_KEY='YOUR_API_KEY'
curl -fG 'https://api.screenshotmachine.com/' \
  --data-urlencode "key=$SCREENSHOTMACHINE_KEY" \
  --data-urlencode 'url=https://example.com' \
  --data-urlencode 'dimension=1280x900' \
  --data-urlencode 'format=png' \
  --data-urlencode 'cacheLimit=0' \
  --data-urlencode 'delay=1000' \
  -o current.png

Python

import os
import requests

params = {
    "key": os.environ["SCREENSHOTMACHINE_KEY"],
    "url": "https://example.com",
    "dimension": "1280x900",
    "format": "png",
    "cacheLimit": 0,
    "delay": 1000,
}
response = requests.get(
    "https://api.screenshotmachine.com/",
    params=params,
    timeout=90,
)
response.raise_for_status()

# The API can return an error image for invalid or incomplete requests.
# Preserve response headers and inspect the image before accepting it as a capture.
with open("current.png", "wb") as image_file:
    image_file.write(response.content)
print("X-Screenshotmachine-Response:", response.headers.get("X-Screenshotmachine-Response"))

Node.js

const key = process.env.SCREENSHOTMACHINE_KEY;
if (!key) throw new Error("Set SCREENSHOTMACHINE_KEY first");

const params = new URLSearchParams({
  key,
  url: "https://example.com",
  dimension: "1280x900",
  format: "png",
  cacheLimit: "0",
  delay: "1000",
});
const response = await fetch(`https://api.screenshotmachine.com/?${params}`, {
  signal: AbortSignal.timeout(90_000),
});
if (!response.ok) throw new Error(`HTTP ${response.status}`);
const bytes = Buffer.from(await response.arrayBuffer());
const fs = await import("node:fs/promises");
await fs.writeFile("current.png", bytes);
console.log("X-Screenshotmachine-Response:", response.headers.get("X-Screenshotmachine-Response"));

ScreenshotMachine says an invalid or incomplete API call returns an error image with a text error message, and provides an X-Screenshotmachine-Response header with an error code. Therefore, do not treat “an image file was saved” as proof that the page capture succeeded. Check the response header and validate the resulting image before comparing it. [c001]

4. Schedule captures and compare them

Approve the initial baseline. Review the image manually, then store it as the expected state.
Run a scheduled job. Use a cron job, CI workflow, or another scheduler you operate. Choose an interval based on how quickly you need to notice changes; the sources do not establish a universally correct interval or a ScreenshotMachine scheduling feature.
Capture using identical settings. Set cacheLimit=0 when each run must be fresh. Use the same viewport, delay, URL, page state, and format.
Validate the result. Fail the run if the API reports an error or the output is not a valid screenshot. Do not let an error graphic replace the baseline.
Compare with the approved image. Save the new capture and a diff or report. Use a pixel tolerance if your comparator supports it, then inspect meaningful changes instead of automatically treating every difference as a defect.
Triage before updating the baseline. Classify each difference as intended, a visual regression, transient page content, capture failure, or rendering noise. Update the baseline only after review.
Notify the owner. Include the URL, capture time, settings, before and after images, and diff so the recipient can act.

For owned sites or test environments, Playwright Test is a documented alternative for baseline comparison: its toHaveScreenshot() assertion generates a reference screenshot and compares later runs, with configurable thresholds such as maxDiffPixels. Its docs warn that OS, browser version, settings, hardware, power source, and headless mode can affect rendering, so run comparisons in a consistent environment. Playwright also documents a stylesheet option for filtering dynamic or volatile elements. This is an adjacent workflow; it does not establish a ScreenshotMachine integration or managed monitoring feature. Playwright visual comparisons documentation. [c003]

5. Control false positives and missed changes

Dynamic text or imagery: Hide or filter timestamps, rotating banners, personalized regions, and other content that is irrelevant to the check. ScreenshotMachine documents hide and click; Playwright documents a stylesheet for volatile elements. Confirm that excluded areas are not themselves important to monitor. [c001][c003]
Cookie and dialog state: Decide whether the baseline should show the consent dialog or the accepted state. Use consistent cookies and, if appropriate, click or hide controls. A different consent state can make otherwise identical captures look unrelated. [c001]
Late-loading content: Increase delay enough for the relevant content to settle. Keep the value fixed. A delay can make the capture slower, and it does not guarantee every site has finished rendering. [c001]
Stale output: Set cacheLimit=0 for fresh captures. Record the setting so stale and fresh images are never mixed unknowingly. [c001]
Wrong capture scope: Match viewport versus full page, selector, or crop to the question. A full-page screenshot may include content far below the fold; a viewport screenshot may miss it. [c001]
Environment drift: If comparisons use a browser-based capture stack, keep OS, browser version, and rendering settings fixed. Playwright notes that host hardware and power conditions can also change rendering. [c003]
Thresholds that are too loose: A large allowed difference can hide a real regression. Tune tolerances against reviewed examples, and inspect critical visual regions separately when needed. [c003]

6. Troubleshooting

Symptom	Likely cause	Fix
Error graphic saved as the screenshot	ScreenshotMachine can return an error image for an invalid or incomplete request.	Check `X-Screenshotmachine-Response`, validate the image, and fail the monitoring run instead of comparing it. [c001]
Invalid or missing key / URL	Required parameter is absent, misspelled, or empty.	Check the request construction and secret configuration; confirm the URL is encoded and absolute. [c001]
Invalid URL	The target URL is malformed or has not been encoded safely.	Pass a complete URL and use a query encoder such as `--data-urlencode` or `URLSearchParams`. [c001]
No credits error	The account has no remaining credits.	Check account usage and current plan details with the vendor; do not assume a retry will resolve a quota issue. [c001]
Invalid selector or crop	The selector does not match the page or the crop values are invalid.	Test the selector against the current DOM; verify crop coordinates and dimensions. [c001]
Unexpectedly stale screenshot	A cached result may have been served.	Use `cacheLimit=0` when freshness is required and record the cache setting. [c001]
Large diffs on every run	Page state, viewport, timing, or rendering environment is changing.	Fix dimensions and state; use a suitable delay; filter unstable elements; keep the comparison environment stable. [c001][c003]
Missed a visible issue	The screenshot scope or diff threshold excludes the affected content.	Check whether the viewport, selector, crop, or allowed pixel difference is too narrow or permissive. [c001][c003]
Request times out	The target or capture took longer than the client timeout.	Choose a suitable client timeout, inspect target availability, and retry according to a bounded retry policy. Avoid treating a timeout as a valid image or silently advancing the baseline.

7. Performance, reliability, and cost

Performance: Every scheduled URL and device combination creates work for your capture pipeline. Full-page images and longer delays can take more time to produce and store than a fixed viewport capture. Keep the scope limited to pages and states that matter, and avoid overlapping scheduled jobs if a previous run is still active.

Reliability: Store captures and metadata durably, validate every response, and preserve the last approved baseline when a capture fails. Use bounded retries for transient request failures, but do not retry an invalid key, invalid selector, or exhausted-credit response as though it were transient. Alert on missing captures as well as visual differences.

Cost: The research sources do not establish ScreenshotMachine’s current price, plan limits, or monitoring costs. Estimate usage from the number of URLs × device or viewport variants × scheduled runs, then verify the vendor’s current terms. Also account for your own scheduler, storage, comparison, and notification infrastructure. No benchmark or universal polling frequency is established by the cited documentation.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request can return a PNG, JPEG, WebP, or PDF. Cookie banners are accepted and removed before the shot, along with 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, 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.

Here is a one-call capture. 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.com -o shot.webp

ScreenshotNeo includes 1,000 screenshots a month free with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan. Sign up for free and get 1,000 screenshots a month with no card.

FAQ

Does ScreenshotMachine schedule captures and send visual-change alerts?

The reviewed API documentation establishes screenshot capture controls, but not recurring schedules, retained history, diff reports, or alerts. Add those through a scheduler and workflow you operate, or verify a separate current offering with the vendor. [c001]

Should I compare full-page screenshots or just the viewport?

Use the scope that matches the risk. A viewport check is focused on what visitors see immediately; full-page capture covers content below the fold. For a specific component, a selector or crop can reduce unrelated changes. [c001]

Can I use Playwright instead?

Yes, for sites and test environments where you can run browser tests. Playwright Test supports reference screenshots and configurable comparisons; keep the rendering environment consistent. It is a separate approach, not evidence of a ScreenshotMachine integration. [c003]

Should every difference update the baseline?

No. Review the cause first. Accept a new baseline only when the changed appearance is intentional and the new image is the state you want future runs to expect.

Sources

[c001] ScreenshotMachine Website screenshot API documentation.
[c002] ScreenshotMachine homepage.
[c003] Playwright: Visual comparisons.