How to compare website changes with Microlink screenshots

To compare website changes with Microlink, capture the page before and after the change under the same conditions, save both screenshot files, and pass them to a visual-diff tool. Microlink’s documented screenshot API captures and delivers images; the comparison step is separate. A diff can show changed pixels, regions, and an image of the differences, but it cannot decide whether a change is a defect.

This guide uses Microlink for both captures and a separate image comparison step. It also shows how to keep the two sides comparable, interpret dynamic changes, and troubleshoot common capture and diff issues.

1. Capture two comparable states

Choose the page and the exact state you want to check. Usually that means the same URL before and after a deployment. If the change is behind a login, requires a click, or depends on a particular page state, make sure both captures reach that state in the same way.

Capture the approved or earlier state and save its screenshot as your baseline.
Make the code or content change.
Capture the same page again using the same capture settings.
Compare the two saved images with a visual-diff tool.
Inspect the original images alongside the diff before deciding whether the change is a regression.

Keep the viewport or device, screenshot scope, color scheme, and any required interactions consistent. A changed viewport can reflow the page; a changed page scope can produce different image dimensions. Either can create a large diff even when the UI change you care about is small.

2. Capture a screenshot with Microlink

Microlink’s screenshot guide uses a request with a target url and a screenshot option. Set screenshot to true for a default viewport capture, or pass an object to configure options such as fullPage, element, and image type. The response includes screenshot metadata, including data.screenshot.url. You can retrieve the image from that URL and save it for later comparison. See the Microlink screenshot guide and screenshot parameter reference.

For a screenshot-only workflow, Microlink documents meta: false as an option that skips metadata extraction and can provide a speedup when metadata is unnecessary. When you need the hosted image URL and its dimensions or type, retain the JSON response instead.

Example: request the screenshot metadata

curl -G 'https://api.microlink.io' \
  --data-urlencode 'url=https://example.com' \
  --data-urlencode 'screenshot=true' \
  -o response.json

This saves the API response as JSON. Read the screenshot asset URL from data.screenshot.url, then download that image and give it a stable name, such as baseline.png or current.png. The screenshot guide also documents embed=screenshot.url when a direct image response is more useful in a markup or pipeline workflow.

Capture options that affect comparisons

Option or condition	How to use it	Why it matters
`screenshot: true`	Request the default screenshot.	Provides a straightforward viewport capture.
`fullPage`	Set it in the screenshot options object when the full page is the target.	Both images should cover the same page scope.
`element`	Set it to capture a specific page element.	Useful for isolating a component; keep the target element and state consistent.
`type`	Choose an image type supported by the API.	Use a consistent format in the pair when possible.
Viewport or device	Keep the dimensions or device setting the same.	Responsive layouts can change substantially with viewport width.
Color scheme and page state	Match light or dark mode and repeat any setup or interaction.	Otherwise the screenshots represent different states.
Browser frame overlay	Omit it for pixel-accurate QA.	The frame and background add pixels that are not part of the page. Microlink advises skipping the overlay for visual regression.

Microlink’s docs describe capturing a rendered page in a headless browser and storing the screenshot on its CDN. The screenshot asset response can include the URL, type, size, width, and height. Treat a saved screenshot as the input to your comparison workflow; the reviewed Microlink documentation does not establish named baselines or a built-in pixel-diff report.

3. Compare the saved screenshot files

Once you have the baseline and current images, use a visual comparison tool that accepts two images, or use a service that captures and compares URLs. The comparison API example reviewed for this guide is published by Screenshot API, a separate service from Microlink. Its documentation describes comparing a live URL with another URL or a named baseline, and returning a changed-pixel percentage, changed-region boxes, and a diff image. Capture parameters apply to both sides in that example so the images line up.

When comparing files locally, the exact command depends on your chosen image-diff library or CI platform. The essential inputs are the two saved images. Avoid presenting a comparison endpoint as a Microlink endpoint: use Microlink to capture and deliver the screenshots, then use a separate comparison tool to compute the diff.

What a diff result means

Changed-pixel percentage: the portion of pixels that differ according to that tool’s comparison rules. It is a signal to review, not a measure of bug severity.
Changed-region boxes: locations that help you focus inspection on affected areas.
Diff image: a visualization of where the images differ; check it alongside both original screenshots.
Threshold: a comparison setting that determines how much difference is needed for the tool to report a positive change. Raising it can tolerate small dynamic effects such as a clock or carousel, but can also hide small changes worth reviewing.

Do not treat every changed pixel as a regression. Text, time-sensitive content, carousels, responsive layout, and inconsistent capture state can all create real visual differences that are expected. No accuracy or false-positive rate is established by the reviewed sources.

4. Make visual comparisons reliable

Control dynamic content

Where possible, use a stable page state: avoid rotating banners, current timestamps, random content, or animations in the area under test. If dynamic content is part of the intended behavior, decide whether it belongs in the comparison and choose an appropriate threshold or review process. Thresholds should be tuned to the page and the cost of missing a small change; they are not a universal pass/fail setting.

Keep the image boundaries aligned

Compare the same page area at the same dimensions. If a full-page capture has different heights because content was added or removed, inspect the originals to distinguish a real content change from a misaligned comparison. For component checks, an element capture can reduce unrelated page changes, provided the same element is captured consistently.

Retain evidence for review

Keep the baseline, current capture, and diff together with the URL and the capture settings used. The screenshot metadata can help identify the image dimensions and type. A human reviewer can then tell whether the changed region matches the intended code change.

5. Troubleshooting

Symptom	Likely cause	What to do
The comparison reports changes across most of the page.	Different viewport, page scope, color scheme, or page state.	Repeat both captures with matching settings and the same route and state.
The saved response is JSON, not an image.	The request returned screenshot metadata rather than a direct image response.	Read `data.screenshot.url` and download that asset, or use the documented `embed=screenshot.url` workflow where a direct image response fits your pipeline.
The screenshot URL is missing from the response.	The request may have failed to capture the target or did not request a screenshot as intended.	Check the response body and confirm the target URL and screenshot option. Do not feed an unsuccessful response into the image comparison step.
The diff highlights a clock, carousel, or changing content.	The page is dynamic between captures.	Stabilize the state if possible; otherwise choose a threshold that fits the review and inspect the original images.
The diff contains a browser frame or decorative background.	An overlay added pixels outside the webpage.	Omit Microlink’s browser-frame overlay for pixel-accurate QA, as its guidance recommends.
A small visual regression does not trigger a changed result.	The comparison threshold may be too tolerant.	Lower the threshold and review the affected area. Threshold behavior depends on the comparison tool.
The request is slower than expected for a screenshot-only task.	Metadata extraction may be unnecessary work.	Try Microlink’s documented `meta: false` option when you do not need metadata; its guide describes this as usually the biggest speedup for screenshot-only requests.

6. Performance, reliability, and cost

Screenshot capture requires a rendered page, so page complexity and loading behavior affect how quickly a usable image is available. For a screenshot-only Microlink request, the guide says meta: false skips metadata extraction and usually offers the biggest speedup. If your workflow needs the screenshot URL and metadata, keep the normal response.

For reliability, save the returned screenshot asset and its metadata as part of the comparison record, and validate that both captures succeeded before asking a diff tool to compare them. A diff over a missing, stale, or wrong-state image can produce misleading output.

Microlink’s reviewed screenshot guide states that the API works without an API key and offers 25 requests per day; it describes production plans as unlocking configurable TTL, stale-while-revalidate caching, custom filenames, custom headers, and proxy. Quotas and plan details can change, so confirm the current terms in the official guide before relying on them in a production workflow.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. For a direct capture call, see the ScreenshotNeo API documentation:

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

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Can I use Microlink for visual regression testing?

You can use Microlink to capture the page states for a visual regression workflow. The reviewed docs establish screenshot capture and delivery; use a separate visual-diff tool to compare the saved images.

Does Microlink itself create named baselines and pixel-diff reports?

The Microlink documentation reviewed here does not establish those features. The comparison endpoint discussed above is from a separate service.

Should I use a full-page screenshot or an element screenshot?

Use a full-page capture when changes anywhere on the page matter. Use an element capture when the check is specifically about one component and unrelated content should stay out of the comparison.

Does a high changed-pixel percentage prove a bug?

No. It tells you how much differs under the tool’s rules. Inspect the originals and decide whether the change was intended.