From screenshot API to visual web infrastructure.
urlshot.io started with reliable website capture. We plan to build on it: keeping the visual state of a page, comparing it over time, watching it on a schedule, and telling you when it changes.
- AvailableCaptureRender any public page in Chromium and get the image back.
- PlannedSnapshotKeep a capture, with an ID, to fetch again later.
- PlannedCompareSee what changed between two snapshots.
- PlannedMonitorCapture on a schedule and compare each run with the last.
- PlannedNotifyAn email or a webhook when something changes.
Stage 1
Capture.
This exists today. Send a URL to the screenshot API; it loads the page in a real browser, runs its scripts, waits for its fonts, and returns the image.
Every other stage on this page builds on this one, and none of them replaces it. What a capture can be asked for today:
- PNG, JPEG or WebP, of the visible screen, the whole page, or one element by its CSS selector.
- Any viewport from 200 to 3840 pixels wide, at up to 3× pixel density.
- Dark mode, consent pop-ups hidden, elements hidden by selector, and your own CSS; your own JavaScript on paid plans.
- Waits for content that loads after the page does, or for the moment you choose.
- Opt-in caching, as long as your plan allows and at most a day; a cached screenshot costs no credit.
- Signed URLs, so a screenshot can sit in an image tag without your secret key.
- https://example.com
- urlshot.io API
- Chromium
- PNG, JPEG or WebP
Stage 2
Persistent snapshots.
Today a screenshot is the response to one request. Unless you cache it, for a day at most, urlshot.io keeps no copy. Snapshots would let you say: capture this page, and remember it.
Monitoring, audits, regression tests and visual archives all need the same thing around every screenshot: somewhere to keep it, a name to find it by, and a record of how it was taken. Today you build that storage yourself. We plan to make it part of the capture.
What a snapshot could carry
- The stored image, under its own ID.
- When it was captured, the URL, and the options it was captured with.
- A history of snapshots of the same page.
- Retention you control: how long each is kept.
- Retrieval through the API and the dashboard.
Concept, not available
- POST /snapshots
- Capture
- Storage
- Snapshot ID
- Retrieve it later
Stage 3
Visual comparison.
Compare two snapshots and find out how the rendered page changed: how much, and where.
It is what turns two images into an answer. A comparison could return a score for how much changed, an image with the changes marked, the regions that changed, and what was compared with what. We have not chosen the method or the response format, and we will not describe either until we have.
Where it would help
- Visual regression testing: a failed check when a deployment moved something.
- Website monitoring: a page that changed since yesterday.
- Deployment checks: production looks as it did before the release.
- Competitor pages: a pricing table or headline that changed.
Concept, not available
- Snapshot A
- Snapshot B
- Compare
- Change score
- Diff image
- Changed regions
Stage 4
Website monitoring.
The first three stages, put to work on a schedule. Give urlshot.io a page and how often to look; each capture is kept and compared with the one before, and a change you care about is flagged.
It is the stage that turns the others into a product you would not have to assemble: today the schedule, the storage and the comparison are all your code, as the website monitoring guide shows step by step.
What we plan to include
- Captures every hour, day or week.
- A history of every capture of each page.
- Each capture compared with the previous one, automatically.
- A threshold for how much change matters.
- A dashboard of your monitors, and how long to keep their history.
Concept, not available
- A URL and a schedule
- Capture
- Snapshot history
- Compare with the previous one
- Change detected
Stage 5
Notifications and webhooks.
A monitor that finds a change should be able to tell someone. We plan to send an email, or a webhook to your own system, when a change passes the threshold you set.
Webhooks are the developer half: a change on a page becomes an event your code receives, so it can open an issue, post to your team’s chat, or roll back a release, in whatever system you already run. An event might be called monitor.changed; its contents are not designed yet.
What we plan to include
- Email when a page changes.
- Webhooks to your own endpoint.
- Thresholds, so a timestamp ticking over is not news.
- A notice when a monitor itself fails.
- An event when a snapshot is ready.
Concept, not available
- Monitor
- Change past your threshold
- Webhook
How it fits together
Built as composable developer primitives.
Not five products. Each stage would be a layer on the one before it, and each would be usable on its own through the API: snapshots without ever monitoring anything, or a comparison of two snapshots you took yourself.
Capture powers snapshots. Snapshots give you history, and something to compare. Comparison is what makes monitoring mean something. Monitoring produces the events that notifications send.
- Screenshot APIAvailableThe request you send today.
- CaptureAvailablePowers everything below it.
- SnapshotsPlannedKeep captures, which gives you history.
- ComparisonPlannedNeeds two snapshots to compare.
- MonitoringPlannedMeans something because of comparison.
- NotificationsPlannedSend the events monitoring produces.
What this will enable.
Every use case works with Capture today. The roadmap would take over the parts you now build around it, and only for the use cases that need them.
Website monitoring
- Capture
- Snapshot (planned)
- Compare (planned)
- Monitor (planned)
- Notify (planned)
Today you run the schedule, keep the images and compare them in your own code.
With every stage built in, a monitor would be one API call and a webhook.
Visual regression testing
- Capture
- Snapshot (planned)
- Compare (planned)
Today your CI keeps the baselines and runs the image diff.
Stored baselines and a comparison endpoint would replace both.
AI agents
- Capture
- Snapshot (planned)
- Compare (planned)
Today an agent sees a page as it is now.
Snapshots and comparison could let it reason about how a page changed over time.
Website thumbnails
- Capture
Works end to end today.
Capture is all it needs.
Link previews
- Capture
Works end to end today.
Capture is all it needs.
Start with screenshots today.
Every stage on this roadmap builds on the screenshot API, and it works now. 100 free screenshots a month, no credit card needed.