Your screenshot API shouldn't need a CSS selector for step 2

FrameJet — Wed, 23 Sep 2026 07:07:00 +0000

Most screenshot APIs let you script the page before capture: click: "#accept", wait_for: ".results", a blob of JavaScript. That covers a lot. It stops covering things when the screenshot you want is several clicks past the URL.

Say you want the revision history of a Wikipedia article, starting from the homepage. Step 1 is "type into the search box". Step 2 is "click the right result". The problem is step 2's DOM doesn't exist yet when you write the request. It only appears after step 1 has run in a live browser. To script the flow you'd have to run the flow first, which means keeping your own browser session open. And if you have one of those, you don't need a screenshot API.

Passing the goal in plain words

Framejet now takes a goal along with the URL:

curl -G -H "X-Api-Key: $KEY" -o shot.png \
  --data-urlencode "url=https://en.wikipedia.org/" \
  --data-urlencode "goal=Search for the Colosseum article, open it, then open its View history page. Stop when the revision list is visible." \
  --data-urlencode "values=Colosseum" \
  "https://framejet.dev/v1/take"

It walks the flow step by step and shoots when the stop condition is met. That exact request comes back as "Colosseum: Revision history" in about 16 seconds, with the site banner already stripped.

Why the navigation isn't done by an LLM

"AI navigates the page" usually means a language model reading the DOM and guessing a selector. Selector guessing is where these systems fail in the way that hurts most: the model names an element that isn't there, or clicks the wrong one and carries on.

The decisions here go to TypeSafe's Jev, a constrained-choice model. Each step, the visible controls are sent as a numbered menu, and Jev answers with one index plus a probability distribution over all of them:

It can't answer with a selector, so it can't make one up.
An off-menu or malformed answer is detectable, so it gets refused rather than executed.
It's fast (roughly a second per decision) and cheap, because it's picking from a list, not writing text.

It doesn't invent the text it types

Anything typed into a field comes from the values you pass. If none of them fits the field in front of it, the capture fails instead of guessing. I didn't want a tool that puts made-up strings into someone else's form.

It fails loudly

This is the rule I'd want as a user: only a reported DONE returns an image. If the navigator reports BLOCKED, runs out of steps, or makes three moves without a page change, the API returns 422 goal_unreached and refunds the credit. A DONE judgment can still be wrong, so check important outputs.

An early version returned 200 with whatever page it ended on in four of those paths. The caller couldn't tell. Fixing that mattered more than any accuracy tweak.

When to use selectors instead (often)

If you know the page, a selector is better: deterministic, instant, free, and it reaches any node. Framejet still takes them:

actions=click:#searchInput;type:#searchInput=Colosseum;wait:1000

Visual regression testing in particular should use actions, not goal. A non-deterministic capture path turns your diffs into noise. goal is for the case a selector can't cover: an agent handed an arbitrary URL at runtime, or the same intent across many sites you don't control.

The rest

Clean mode is on by default. Consent walls and chat widgets are removed before the capture, not cropped after. This matters more when a vision model reads the result, because a screenshot of a cookie banner tells it nothing.
REST and a remote MCP server share one key and one quota. The MCP tool is screenshot(url, goal, values, actions, …), listed as dev.framejet/screenshot on the official MCP registry and framejet/screenshot on Smithery. There's nothing to install.
Limits: a single region (US East), a hard time limit of under a minute per capture, and goal mode is new, so some pages won't work. I'm genuinely interested in the ones that fail.

Have a public page that takes a few clicks to reach? Share the URL and the screen you need in a comment. I can try it with Framejet and reply with the request that worked, or the failure if it didn't.

200 screenshots a month free, no card: framejet.dev

Why your headless screenshots have a cookie banner over them (and how to get rid of it)

FrameJet — Thu, 17 Sep 2026 10:35:58 +0000

If you have ever automated screenshots with Puppeteer or Playwright, you've seen it: the page renders perfectly, and then a consent wall covers half of it.

Why it happens

A headless browser starts with an empty profile. No cookies, no stored consent. To every website it is a brand-new visitor, and brand-new visitors in the EU (and increasingly everywhere) get a consent banner. Your screenshot is just faithfully recording what that visitor sees.

Option 1: accept the banner first

Click "Accept" before capturing:

await page.goto(url, { waitUntil: "networkidle2" });
const btn = await page.$('#onetrust-accept-btn-handler');
if (btn) await btn.click();
await page.screenshot({ path: "shot.png" });

It works for one site. It breaks the moment you capture a site using a different consent platform, a different button id, or a banner inside an iframe.

Option 2: hide the overlays

Instead of interacting, remove the elements:

await page.addStyleTag({ content: `
  #onetrust-consent-sdk, #CybotCookiebotDialog, .fc-consent-root,
  [id^="sp_message_container"], #didomi-host { display: none !important; }
  html, body { overflow: auto !important; }
`});

Two details people miss: many banners lock scrolling on <body>, so you must restore overflow, and some leave a dark full-screen backdrop that is a separate element from the dialog. A selector list gets you most of the big platforms; for the long tail you need a heuristic, e.g. fixed-position elements covering most of the viewport with a high z-index.

Chat widgets (Intercom, Drift, HubSpot...) and sticky headers are the same problem in a different place. The sticky header is especially bad on full-page captures, where it can repeat down the image.

Option 3: use a service that does it for you

This is the part where I mention that I got tired of maintaining that selector list and built Framejet, a screenshot API with this on by default:

curl -H "X-Api-Key: $KEY" -o shot.png \
  "https://framejet.dev/v1/take?url=https://example.com&full_page=true"

It removes consent overlays, sticky headers and chat bubbles before the capture, doesn't charge for failed captures or cached repeats, and has an MCP server if you want an AI agent to take screenshots. There's a free tier of 200 screenshots a month. Other APIs (ScreenshotOne, Urlbox, ApiFlash) solve this too, so pick whatever fits your volume and budget.

Whatever you choose, the underlying trick is the same: treat overlays as a rendering problem, not a clicking problem.

DEV Community: FrameJet