Responsive bugs hide at widths nobody tested. A layout looks fine at 1280 pixels and breaks at 390, where most of your traffic is.
The screenshot call renders a URL and captures it at the viewports you ask for, all in one request. Instead of juggling a headless browser, a resize loop and image storage, you ask once and get the set back.
What it is good for
- Visual QA. Capture the same pages at desktop, tablet and phone widths before and after a change, then compare.
- Archives. Keep a record of what a page looked like on a given day. Handy for competitor tracking and compliance.
- Design review. Show a client the live site at the sizes they care about without a screen share.
- Agent vision. Give a model a picture of the page next to its Markdown.
Rendered, not fetched
The page is loaded in a real browser engine and captured after JavaScript has run, so client-rendered content, lazy sections and web fonts show up as a visitor sees them.
Pair it with the rest
Screenshots sit well beside brand extraction for a design-handoff packet, and beside Markdown scrape when an agent needs both the picture and the text. See design handoff.
Pricing is by page against your monthly quota, and the Free plan covers 100 a month to test with.
Choosing viewports that mean something
The call captures at the widths you ask for, so the useful question is which widths. Three cover most of the ground: a desktop width around 1280 pixels, a tablet width around 768 and a phone width around 390. Those are the points where layouts usually change, which is where bugs hide. Add a fourth only if you have a reason, such as a wide monitor for a dashboard product. More widths means more captures against your quota, and the extra ones rarely show anything the first three did not.
A before-and-after routine
The most reliable use is a routine you repeat. Before you ship a change, capture your key pages at the three widths and save the set. After the change, capture again and put the pairs side by side. You are looking for the boring failures: a menu that wraps onto two lines, a button pushed off screen, text that overlaps an image, a table that forces horizontal scroll. Those are exactly the problems a quick look at your own laptop misses.
Keep the file names predictable, with the page, the width and the date in the name. A folder of captures with no naming convention is a pile, not a record.
Pages that need care
Some pages are hard to capture well. A page that loads content as you scroll may show only the first screen unless the content is in place when the capture happens. A page behind a cookie banner will show the banner. A page with a video or animation captures a single frame. None of these are bugs in the capture, but they are worth knowing before you build a process on top of it. Check a few captures by eye before you trust a batch.
Using screenshots with a model
A picture and the text of a page together give a model more than either alone. Send the screenshot and the Markdown of the same URL, and ask about layout and content in one question. That is useful for design critique, for accessibility spot checks and for describing a page to someone who cannot see it.
Ownership and privacy
Capture pages you are entitled to read. A screenshot of a public page is fine for QA and research. Do not point the tool at pages behind a login or at private systems, and do not capture personal data you have no reason to hold.