Crop a web page down to one region, and keep it running

The part you want is usually a fifth of the window

Open the page you check most often and measure it honestly. The number you care about might occupy a couple of hundred pixels. Everything else — masthead, navigation, related links, footer — is there for a reader who arrived from search, not for you, who arrived for the eleventh time today.

That is fine when the page has your whole screen. It stops being fine the moment you want six of them at once. Six full pages tiled on one display means six sets of chrome competing for the same pixels, and the thing you are watching ends up smaller in each one.

Why the usual workarounds don't hold up

Screenshots

A screenshot crops perfectly and then immediately begins to lie. It shows the number as it was, not as it is. For anything you are monitoring — a price, a build, a queue — a frozen image is worse than no image, because it looks current.

Browser zoom

Zoom changes the scale of the entire document. It cannot show you one region larger; it shows you all regions larger, so you end up scrolled to roughly the right place and one layout reflow away from losing it.

User scripts and injected CSS

Hiding everything except one selector works beautifully until the site ships a redesign, renames a class, or moves to a new framework. Then it breaks silently, and you find out when you notice you have been staring at an empty box. Every page you do this to becomes a small piece of software you now maintain.

Iframes

The instinct of anyone technical is to embed the pages in a grid of iframes. The sites worth watching are precisely the ones that refuse to be framed, and the ones you are logged into generally won't carry the session into a frame. That deserves its own page: why you can't build this with iframes.

What cropping a pane actually does

SplitWeb takes a different route. Each pane is a real web view loading the page as a normal top-level document, exactly as a browser would. Cropping never changes what is loaded — only what is shown.

You open the crop window for a pane, which shows an enlarged snapshot of the page so you can drag a selection box comfortably even when the pane itself is small. Drag the box around the region you want, apply it, and the pane keeps that region, scaled up to fill the pane. Everything outside the box is clipped away.

The page underneath is still live. It is the same web view, still rendering, still fetching, still logged in. The number inside your crop updates because the page updates. Nothing about the crop is a capture.

Resize the pane and the region stays put

This is the detail that separates a crop that survives daily use from one that doesn't. A naive implementation stores the selection against whatever size the pane happened to be, so the first time you drag a divider, the visible region drifts to some other part of the page and you have to redo the selection.

SplitWeb records the pane's size at the moment you crop and keeps rendering the page at that base size. Resizing the pane only changes the scale factor applied on top. The selected region is the same region an hour later and after a restart — bigger or smaller on screen, never somewhere else on the page.

Layouts persist too. URLs, splits and crop regions come back the way you left them the next time you open the app.

The trade-off you should know about first

This is a deliberate consequence of how the crop works: the web view is scaled up and extends past the edges of its pane, so it stops accepting hit testing and the pane's own controls stay usable. In practice it matches how these panes get used — a cropped pane is something you watch, and the ones you work in are left uncropped.

Two other things worth knowing before you buy: every pane holds its own live web view, which is what keeps pages from reloading when you rearrange the board and also what makes memory use climb as you add panes; and SplitWeb is not a replacement for a browser — no extensions, no bookmark sync, no tab management.