Element screenshots: capturingone part of a page
instead of all of it
If you only care about the pricing table, capturing the whole page means every unrelated change — a new banner, a rotated testimonial — looks like a change to the thing you are watching.
Why whole-page captures make comparison hard
Monitoring a competitor's pricing sounds simple: capture the pricing page every day and look for differences. In practice the first week produces a stack of images that all look different, because almost everything on a modern page moves.
A rotating testimonial. A cookie banner that appears on some loads. A promotional bar that changes on Mondays. A footer with a live customer count. None of these are what you are watching, but all of them make today's capture differ from yesterday's — and once every image differs, differences stop meaning anything.
Element capture removes the noise at source. Instead of photographing the page and hoping the interesting part stayed put, you tell the renderer which element you care about and get an image of exactly that.
How element capture works
Point at a node, get that node.
You supply a selector — an XPath expression identifying a node in the page — and the renderer waits for that element, scrolls it into view, and captures its bounding box rather than the viewport.
That last detail is what makes it useful. The output is cropped to the element itself, so the image size is determined by the component rather than by the browser window. A pricing table captured this way produces the same framing whether the page around it grew or shrank.
- The element must exist and be visible; a selector that matches nothing cannot be captured.
- Elements that load late need the same waiting strategy as any other dynamic content.
- A selector matching several nodes is ambiguous — be specific enough that it matches one.
Our element capture documentation covers the selector syntax and the actions that can be run before the capture.
Writing selectors that survive a redesign
The failure mode of element capture is not a bad image, it is a selector that stops matching six months later. Some selectors are far more durable than others.
- Prefer stable identifiers. An id, a data attribute, or an ARIA role tends to outlive a redesign. Generated class names change every build.
- Avoid deep positional paths. A selector that walks eight levels of divs breaks the first time someone adds a wrapper. Anchor to something meaningful and go down from there.
- Anchor on text where the text is the point. A section identified by its heading is often more stable than one identified by its position.
- Test against the mobile layout too. Responsive pages frequently render a different node for small screens, so a desktop selector may match nothing on a phone profile.
Where element capture earns its place
- Price and plan tables. The canonical case. The table changes rarely and meaningfully; the page around it changes constantly and meaninglessly.
- Availability and stock indicators. A small component whose state is the entire point of watching the page.
- Legal text and disclaimers. Capturing the clause rather than the page makes a change obvious at a glance in an archive.
- Charts and dashboards. A chart cropped to its own bounds is far more usable in a report than a screenshot of a whole dashboard.
- Design system components. Capturing a component in isolation gives visual regression checks a much cleaner baseline.
When a full-page capture is still the right answer
Element capture is a precision instrument, and precision is the wrong tool for some jobs.
- Evidence and compliance. A cropped component is a weaker record than the whole page. If the question is what a customer saw, capture what a customer saw.
- Layout questions. Whether something sits above the fold, or how much space a banner occupies, is a property of the page and disappears the moment you crop.
- Pages you do not control and do not know well. Writing a durable selector requires understanding the markup. For an unfamiliar page, start with full-page captures and narrow down later.
For those cases the full-page capture remains the default, and compliance records should almost always use it.
FAQ
What selector syntax do you support?
XPath expressions, which can identify an element by id, attribute, class, role or text content, and can be combined for precision.
What happens if the element is not found?
There is nothing to capture, so the run does not produce an image. Treat that as a signal that the page changed rather than as a transient failure.
Can I capture several elements from one page?
Set up one capture per element. Each gets its own selector and its own history, which is usually what you want anyway since they change independently.
Does element capture work on a schedule?
Yes — the selector is part of the capture profile, so every scheduled run captures the same component.
Is the image cropped or is it the full page with a highlight?
Cropped to the element's bounding box. The output contains the component and nothing else.
TL;DR
Whole-page captures are noisy: everything on the page moves, so every image differs and differences stop being informative. Element capture crops to the component you actually care about, which makes visual comparison meaningful again. Anchor selectors on stable identifiers rather than generated classes or deep positional paths, alert on an empty result rather than ignoring it, and keep full-page captures for evidence, layout questions and pages you do not know well.