Pageshot

Why a real browser matters

A screenshot service that fetches HTML and guesses is a rendering engine pretending to be a browser, and it gets modern pages wrong — web fonts, CSS grid, lazy images, anything drawn by JavaScript after load. This runs actual Chrome, so what you get is what a visitor would have seen.

Full-page captures scroll the page first. That sounds like a detail and is not: images below the fold on most modern sites use loading="lazy" and never load at all unless something scrolls past them. A full-page capture taken without scrolling is mostly empty placeholders.

Choosing a width

The width sets the viewport, which is what CSS media queries respond to — so 390 genuinely renders the phone layout rather than shrinking the desktop one. That makes this useful for checking a responsive breakpoint without resizing your own window and losing your place.

2× resolution doubles the device pixel ratio, the way a retina display does. Use it for anything going into documentation or a slide deck, where a 1× capture looks soft on a modern screen. It quadruples the file size, so leave it off otherwise.

Three widths in one go

Choosing all three captures 390, 768 and 1440 from a single page load, and gives you a tab per width. Checking a breakpoint is the reason most people open a screenshot tool at all, and doing it one width at a time means three waits.

One load rather than three is deliberate, and not only for speed. Loading a page three times is three times the traffic to someone else's server — and because ad slots, A/B assignments and personalisation differ per load, it produces three captures that are not actually of the same page. Resizing is what you would do by hand.

The limit worth knowing: a site that picks its layout from the user agent or from touch support at load time keeps the layout it loaded with, so the narrow captures will look like a squashed desktop rather than the phone design. CSS media queries — how responsive design is actually done — re-run correctly. If a narrow capture looks wrong, capture that width on its own and compare.

2× resolution is unavailable for the three-width set: three full-page captures at double the pixel density is four times the bytes of something already large, and the run would hit its size limit and hand back one picture instead of three.

What will not capture well

Pages behind a login, obviously — there is no session to use. Beyond that: cookie banners appear in captures because they appear for a first-time visitor, which is honest but rarely what you wanted. Sites with aggressive bot protection may serve a challenge page instead of their content, and animations are caught at whatever frame they happened to be on.

Very long pages are cut off. Capturing an infinite-scroll feed would otherwise mean scrolling until the server ran out of memory, so there is a height ceiling and the capture stops there.

PNG or JPEG

PNG is lossless and right for anything with text, sharp edges or flat colour — which is most web pages. JPEG is smaller for image-heavy pages and photography, at the cost of softening text.

For a full-page capture of a long site, JPEG can be several times smaller. For a single viewport of an interface, PNG is usually both smaller and sharper, because interface screenshots are exactly the flat-colour content JPEG handles worst.

Capture any public page as an image — viewport or full length, at whatever width you need, or all three of phone, tablet and desktop from a single page load. Rendered by a real browser on the server, so the result is what a visitor would see rather than what a preview service guessed.

It's one of the free tools in the util.quest collection — nothing to install, and no account needed. Found a bug or want a feature? Reach out at [email protected].