Submit a list of URLs and get an image of each page back - at the viewport size you pick or the full scroll height, as PNG, WebP, JPEG or PDF. Seven columns per row, one of which is a link to the file. Read the note on the status column before you automate anything on it.
We opened every image behind this page rather than trusting the column that says it worked. That turned out to matter.
We hold three real exports covering four rows and two URLs. status reads ok on all four, every image file exists, and every one is a valid PNG at exactly the requested 1200 × 800. On those signals alone, four out of four look like successes.
Two of them are not. Opened, the two earlier captures of the same site are unstyled wrecks - broken image placeholders, a raw “Toggle Navigation” button, a stray oversized graphic - the page caught before its CSS and assets arrived. The other two are correct: a full, properly styled homepage, and a pricing page that looks exactly as it should. Same URL, same ok, completely different result.
The cheap tell is file size. The two broken captures are about 15 KB each; the two good ones are 182 KB and 953 KB. A styled page with images is simply heavier than a page that failed to load its stylesheet. So if you are automating this, threshold on byte size and spot-check the outliers - and do not treat status as a rendering guarantee, because it is not making that claim.
A URL is the input. Three optional settings decide what the image looks like.
The documented defaults are 1200 wide by 800 tall - the size every capture behind this page used. Full-page capture overrides the height. The format parameter accepts WebP, PNG, JPEG and PDF, and defaults to WebP.
Measured from 3 real exports covering 4 rows and 2 URLs, with the same seven columns in the same order every time. Names are copied byte-for-byte from the header row.
https://outscraper.com, https://stripe.com/pricing. Note the reference calls this field query; the export calls it url.ok on all four rows we hold. It reports the capture, not the rendering; see the section above before you build on it.png on every row here. The reference lists WebP, PNG, JPEG and PDF, with WebP as the parameter's default, so our runs asked for PNG explicitly.1200 on every row, matching the documented default. The delivered files measure exactly 1200 pixels across.800 on every row, again the documented default, and again matched exactly by the files.false on every row we hold, which is why these are above-the-fold images. Setting it overrides height./api/screenshoter/file/<run-id>/<n>.png, numbered from zero within the run. A two-URL run produced 0.png and 1.png under the same run id.Every column carried a real value on every row, and every referenced file existed. The schema is stable - seven names, same order, three runs. What the table cannot tell you is whether an image is any good: all four of ours were valid PNGs at exactly the requested dimensions, and two of them were unstyled failures. That is a property of screenshotting rather than of this export, and it is why the honest advice is to threshold on file size and look at the outliers.
Each of these came out of opening the actual files rather than reading the export, which is why they are worth the space.
The two broken captures in our set are about 15 KB; the two correct ones are 182 KB and 953 KB. A page that lost its stylesheet compresses to almost nothing, so byte size separates them cleanly when status cannot. Pick a floor that suits your targets, flag anything under it for review, and re-run those rather than shipping them.
Our capture of a pricing page came back showing UK rates - percentages in pence, a line about EU cards - because the site served the version for the region the request came from. Anything that varies by geography will vary in your screenshots too: prices, currencies, availability, consent banners and language. Worth knowing before you use these as evidence of what a customer elsewhere sees.
screenshot holds a path, not an absolute URL: /api/screenshoter/file/<run-id>/<n>.png. The number restarts at zero for each run, so 0.png is only unique when paired with its run id. Key your storage on the pair, or a second run will overwrite the first.
full_page was false on every row we hold, so each image is the top 800 pixels rather than the whole document - our pricing capture stops partway down the page. If you need the full article or the footer, set the full-page option, which overrides the height rather than working alongside it.
Anywhere a page needs to be preserved as it looked, rather than as it reads.
Copy changes, layouts change, offers appear and vanish. Capturing a set of competitor pages on a schedule gives you a visual diff over time that no text scrape provides - and the pricing page you screenshotted last quarter is often the only record that it ever said what it said.
Advertised claims, terms, disclosures and promotional pricing all need to be evidenced as they appeared on a date. An image with a timestamp is the artefact auditors and legal teams actually ask for, and one row per URL makes a whole estate straightforward to capture.
Directories, dashboards and link cards all want an image of the destination. The same run doubles as a smoke test of your own estate - a page that comes back at 15 KB when its neighbours are 400 KB is usually telling you something is broken.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. Spend a few on pages you know well and open the images - that is the only way to learn what a good capture weighs for your targets, which is the number your quality check will use.
Roughly $2 per 1,000 pages, one row per URL - exact to budget, because a page that captures badly still returns exactly one row and is billed like any other.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams capturing a large page set on a schedule. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.A screenshot preserves how a page looked. These two tell you what it is made of and who registered it.
The technology behind the page - CMS, ecommerce platform, analytics, CDN and web server. An image plus a stack tells you both how a site presents itself and how it is put together.
The registration record behind the domain - registrar, age, expiry, lock status and nameservers. Useful context when a captured page belongs to someone you have not dealt with before.
Lighter than most of this catalogue, with two caveats that are worth stating rather than glossing.
A screenshot records what a public web page showed to an ordinary visitor. That is the same observation any browser makes, saved rather than discarded, and it is why capturing public pages sits at the mild end of what we do. Nothing here logs in, and nothing here defeats a paywall.
Two caveats. First, a page can contain personal data - a team page with names and photographs, a review with an author, a profile card - and a screenshot captures it as faithfully as text extraction would, while being harder to redact later. Think about what is in frame before you archive at scale. Second, the image is someone else's copyrighted layout and content; using captures internally for monitoring, QA or evidence is ordinary practice, and republishing them is a different question that depends on your jurisdiction and purpose.
On our side: publicly available pages only, nothing behind a login, no third-party trackers on the data layer, and your exports - including the image files - auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
status read ok on every one, all four were valid PNGs at exactly the requested size, and two of them were unstyled wrecks caught before the page's CSS and assets loaded. Judge quality by file size and by looking at the outliers, not by that column.url, status, format, width, height, full_page and screenshot. The last is a path to the image file itself, of the form /api/screenshoter/file/<run-id>/<n>.png. Every column carried a real value on every row we hold, and every referenced file existed.Paste your URLs and get an image of each one, at the size and format you choose. Your first 500 rows are free - spend a few of them opening the files, so you know what a good capture weighs before you automate the check.
Some things about a web page cannot be captured as text. A layout, an offer banner, the arrangement of a pricing table, the way a claim was presented on a particular day - those are visual facts, and the artefact that preserves them is an image. This service produces one per URL: submit a list of pages and each comes back as a row carrying the capture settings and a link to the file. The viewport defaults to 1200 by 800 pixels, full-page capture is available and overrides the height, and the output format can be WebP, PNG, JPEG or PDF.
The export carries seven columns, and behind this page sit three real runs covering four rows and two URLs. Every column held a real value on every row, the seven names appeared in the same order each time, and every image the export referenced actually existed on disk at exactly the dimensions requested. The image path is relative and numbered from zero within a run, so a two-URL job produced 0.png and 1.png under one run id - which means the file number is only unique when paired with that id, and storage should be keyed on the pair.
The most useful thing this page can tell you came from opening the files rather than reading the spreadsheet. The status column read ok on all four rows. Two of the four images are correct: a properly styled homepage and a pricing page that looks exactly as it should. The other two, captures of the same site taken earlier, are unstyled wrecks - broken image placeholders, a raw navigation toggle, a stray oversized graphic - the page caught before its CSS and assets arrived. Same URL, same ok, entirely different outcome. So status reports that the capture completed, not that the page rendered, and anything automated on top of it needs a second signal. File size is the cheap and effective one: the two broken captures weigh about 15 KB each while the good ones weigh 182 KB and 953 KB, because a page that lost its stylesheet compresses to almost nothing. Set a floor, flag what falls below it, and re-run those rows. One further observation worth carrying into any monitoring job: the pricing page we captured came back showing UK rates, because sites serve the version appropriate to the region a request comes from - prices, currencies, availability, language and consent banners will all follow the capture location rather than yours.
The common uses follow from that. Competitive monitoring benefits from a visual record that text extraction cannot produce, and the screenshot taken last quarter is often the only proof a page ever said what it said. Compliance and legal teams need exactly that kind of dated evidence for advertised claims, terms and promotional pricing. Directories and dashboards need thumbnails, and the same run doubles as a smoke test of your own estate. On the legal side, a screenshot records what a public page showed an ordinary visitor, and nothing here logs in or defeats a paywall. Two caveats are worth stating plainly: a capture can contain personal data such as names and photographs on a team page, and it is harder to redact after the fact than text; and the image is someone else's copyrighted layout, so internal monitoring, QA and evidence are ordinary practice while republishing is a separate question. Publicly available pages only, no third-party trackers on the data layer, and exports including the image files auto-delete after 30 days. Your first 500 rows are free and need no credit card.