Page inspector

What the page inspector extracts

Paste a URL and the tool opens it in headless Chrome — real Chrome, not a parser. It waits for JavaScript to finish, fonts to load, lazy images to appear. Then it walks the rendered DOM and pulls out six categories of elements: headings (h1 through h6), interactive elements (links and buttons), form fields (inputs, selects, textareas), images (with src, alt, and dimensions), navigation blocks, and visible text nodes. Each element comes back with a bounding box — x, y, width, height in page pixels — so you know exactly where it sits.

That bounding box is what separates this from a raw HTML parser. Scrapers can read the source. They can't tell you that your CTA button starts at pixel 591, sits 234px wide, and is partially hidden behind a sticky header on mobile. The inspector can, because it measures the rendered layout after CSS and JS have done their work.

How the inspector differs from Chrome DevTools

DevTools shows you everything. Every div, every span, every text node, every pseudo-element. On a typical marketing page that's 800 to 2,000 DOM nodes. Good for debugging CSS. Terrible for answering a simpler question: what can a visitor actually click on this page?

The inspector filters. It returns the elements a human (or an AI agent) cares about: things you can read, things you can click, things you can fill in, and images. On the same marketing page, that's usually 40 to 80 items. Each one labelled by type, with its text content or alt attribute, its position, and a coloured box on the screenshot so you can confirm it visually.

DevTools also requires you to have the page open in your browser. The inspector runs in the cloud. Hit it from a CI pipeline, a monitoring script, or an AI agent that needs to understand what's on a page before it acts. No browser window needed.

Six element categories and what they tell you

Headings show the document outline. Search engines and screen readers rely on heading hierarchy to understand page structure. If your h1 appears at y:1200 instead of y:80, something pushed it down — probably a hero image or a consent banner. The inspector makes that visible instantly.

Interactive elements are links and buttons. Every anchor tag and every button, with its href or click target, its visible text, and its bounding box. Running accessibility audits? You can check whether clickable areas meet the 44px minimum tap target. Building an AI web agent? This is the action space — the full list of things your agent can interact with.

Forms list every input, select, and textarea on the page. Name attributes, placeholder text, field type (email, password, text), and position. Useful for testing whether forms render correctly across devices, and for automated form-filling pipelines where you need to know which fields exist before submitting anything.

Images come with src, alt text, rendered width and height, and natural (original) dimensions. An image rendered at 400px wide from a 2400px source file is downloading six times more data than necessary — and the inspector flags that relationship without you opening a single DevTools panel.

Navigation picks up nav elements and structured link groups. Header nav, footer nav, sidebar menus. Position data tells you whether your navigation appears above the fold or gets pushed below it. (I've seen sites where a promotional banner shoves the entire nav off-screen on mobile. The coordinates catch that immediately.)

Text captures visible text blocks — paragraphs, list items, standalone spans. Coordinates included. Handy for content verification: is the right copy actually rendering on the live page, in the right spot?

Why real-browser rendering matters for element extraction

About 70% of the web runs some form of client-side rendering. React hydration, Vue mounting, dynamic content injection, A/B testing scripts that swap headlines after load. A static HTML parser sees the pre-rendered markup and stops there. The inspector sees what the visitor sees, after all that JavaScript has executed.

Lazy-loaded images are a good example. Below the initial viewport, many sites use loading="lazy" or Intersection Observer to defer image loading. A parser reads the placeholder; it doesn't trigger the load. The inspector scrolls the page internally and waits for images to appear, so the element list includes images that only exist after scrolling — the ones a parser misses entirely.

Consent banners are another case worth calling out. A GDPR dialog that covers 60% of the viewport on mobile doesn't exist in the raw HTML. It's injected by a third-party script after page load. The inspector captures it, along with its exact dimensions. Does that banner cover your h1? The page analysis screenshot and coordinates make it obvious.

Use cases that come up most

SEO audits. You need the heading structure of a page — with positions — to check whether the h1 is visible above the fold and whether heading levels follow a logical order. The inspector gives you that without opening each page manually. Run it across 50 URLs from a script and you have a structured heading audit in JSON.

Accessibility testing. Tap targets smaller than 44x44px, images without alt text, form fields without labels — the inspector returns the raw data to flag all three. Bounding boxes let you calculate touch target size programmatically. Missing alt text shows up as an empty string in the image results.

AI web agents. This is the newer use case, and the one growing fastest. An AI agent that needs to interact with a web page needs to know what's on it: which elements are clickable, where they sit, what text they contain. The inspector returns exactly that structure. Feed the JSON to an LLM and it can reason about page layout, decide what to click, plan a navigation path. Vision models can look at a screenshot, but they struggle with precise coordinates — research keeps showing that VLMs mispredict bounding boxes by tens of pixels. Pre-computed coordinates from the inspector are exact. It's the "eyes" for agents that don't run a browser themselves.

Content verification. After a CMS deploy, did the right headline, the right images, and the right CTA appear on the live page? The inspector's element list is a machine-readable snapshot of what's actually rendered. Compare it against expected values in a test script and you have post-deploy verification without Selenium or Playwright.

Competitive monitoring. Track what elements appear on a competitor's pricing page over time: how many CTAs, where they sit, what copy they use, whether they added a new form field last week. The inspector runs on any public URL — no login, no browser extension.

Page elements to JSON — how the API returns data

The free tool above calls the same endpoint you'd use from your own code. A single request with the URL and optional parameters (device, which element categories to include) returns JSON with two top-level keys: a metadata block and a results block.

Metadata includes page title, final URL after redirects, viewport dimensions, total page height, and the screenshot URL if you asked for one. The results block contains arrays grouped by category. Each element has:

• tag — the HTML tag (a, button, input, img, h1, and so on)
• text — visible text content or alt text for images
• attributes — relevant attributes (href, src, name, type, placeholder)
• box — bounding rectangle: {x, y, width, height} in CSS pixels

No DOM tree, no CSS rules, no nested nodes. Flat arrays of elements that matter, with positions. A typical response for a marketing landing page is 4-8 KB of JSON — small enough to pass straight into an LLM context window without truncation.

Element coordinates in CSS pixels — what the bounding boxes mean

Every bounding box uses CSS pixels relative to the top-left corner of the full page (not the viewport). If a page is 4,800px tall and an image sits at y: 3200, that's well below the fold — roughly two-thirds down. The viewport height from metadata tells you where the fold line falls, so calculating above-fold vs. below-fold for any element is straightforward arithmetic.

On retina captures (2x device pixel ratio), the bounding box stays in CSS pixels. The screenshot image itself is 2x resolution, so to map coordinates onto screenshot pixels, multiply by the device pixel ratio. For standard 1x captures the values map 1:1.

One edge case worth knowing: elements hidden by overflow: hidden on a parent. The element exists in the DOM and has a bounding box, but the visible portion may be clipped. The screenshot shows the truth — if you can see the coloured box on the screenshot, the visitor sees it too. If the box extends beyond a clipped container, only the visible part matters.

Calling the inspector from code

The free tool above works for spot checks. For anything automated — CI steps, monitoring crons, AI agent pipelines — call the API directly.

curl "https://api.screenshotrun.com/v1/render-analyze" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d "url=https://example.com" \
  -d "include[]=headings" \
  -d "include[]=interactive" \
  -d "include[]=images" \
  -d "with_screenshot=true"

The include parameter filters which categories come back. If you only care about headings and images, skip the rest — the response shrinks and rendering is marginally faster because the browser skips bounding box computation for elements you won't use.

Device emulation works the same way as the screenshot API: pass device=mobile or set explicit width and height values. Elements and positions reflect that viewport, which is how you test whether a CTA appears above the fold on a phone without actually pulling out a phone.

Response time depends on the target page. A fast static site returns in 2-3 seconds. A heavy SPA with third-party scripts might take 8-12 seconds because Chrome waits for network idle before extracting elements. The timeout parameter defaults to 30 seconds.

FAQ