01 The Itch
Content design runs on exact pixel boxes. OG images are 1200×630. LinkedIn documents are 1080×1350. Store listings want 1280×800. Every week I need a live web page captured at one of those sizes, and every screenshot tool I tried captures something else: my screen.
A screenshot tool captures whatever your monitor happens to be. If the target size is taller than your display, you get scrolling, stitching, or scaling. Scaling is the quiet liar of the three: it resizes the pixels but not the layout, so text lands at sizes nobody designed and breakpoints that should have fired never do.
What I actually wanted is a tool where the size is an input, not a consequence of my hardware. Type 1920×1920, get a 1920×1920 file, laid out by the browser as if a 1920×1920 display existed. So I built it.
02 The Trick
Browsers can lie to a page about the display it lives on. The Chrome DevTools protocol calls it a device metrics override: tell the renderer the screen is any size you like, and the page re-lays-out for real. Media queries fire, grids reflow, fonts stay at their designed sizes. Then capture exactly that box, pixel for pixel.
The renderer is told the display is exactly the requested size, at 1x or 2x pixel density
Width-dependent media queries, lazy images and fonts get a beat to respond to the new reality
A page shorter than the box is padded by its own background; a longer one is cropped at the requested height. The file is always exactly the size you typed
The override is cleared and the tab returns to its true size. The test suite asserts this too, because a tool that leaves your tab broken is not a tool
The ceiling is Chromium's own: 16,384 pixels per side. Below that, any rectangle is legal, including ones no monitor has ever shipped in.
03 One Engine, Two Bodies
The same capture logic wears two different bodies, because the two jobs are different.
Driven by Playwright. Point it at any URL, or ten URLs at three sizes each, and it writes correctly named files in one pass. This is the batch workhorse: every screenshot on this page came out of it
Captures the tab you are looking at, which means it works behind logins: dashboards, member areas, your own drafts. One popup, type a size, done
The extension needs Chrome's debugger permission, and I will be honest about it the way its store listing is: no other extension API can lay a page out at a size bigger than your window. It attaches for the length of one capture that you triggered, shows Chrome's yellow debugging bar while it works, and detaches immediately after. If that bar bothers you, the local tool does the same job without it.
04 Proof Over Promise
A capture tool has one promise: the file is the size you asked for. So the test suite opens a real browser, requests a spread of sizes including deliberately absurd ones, and then reads the width and height bytes straight out of the PNG headers. Not "the API said it worked": the actual pixels in the actual file, at 1x and at 2x density, plus a final assertion that the tab's real viewport came back.
05 What It Deliberately Isn't
It isn't a SaaS, and that's a decision, not a gap. Screenshot APIs are a crowded, funded category whose real product is a server farm. My html-to-figma plugin taught me the better pattern for a solo builder: make the user's own browser do the work, charge nothing, collect the reputation.
No hosted version: your captures never touch anyone's server, including mine
No account, no telemetry, no quota. The engine runs where you are
No Firefox port yet: Firefox has no debugger API for extensions, and pretending otherwise would ship a worse tool
06 Where It Goes Next
The extension is packaged and store-ready: manifest, privacy policy, permission justifications, the lot. It heads to the browser stores next, and this page gets the install button the day it's live. The engine already earns its keep here every week, making the exact-size assets this portfolio runs on.
Want a tool like this built inside your team, or a design partner who ships end to end? I take on projects.