You take a full-page screenshot to share with a client. Open it up. The sticky header appears four times down the page, three images are blank placeholders, and the bottom 200px is cut off. You've spent 3 minutes and have nothing useful. A proper full page screenshot Chrome extension handles all of this — but most don't, and here's why.
Why basic scrolling screenshots break
The naive approach stitches together viewport-sized snapshots taken while scrolling. It fails in predictable ways on almost every modern site:
- Fixed and sticky elements — navbars, cookie banners, and floating CTAs appear in every capture segment and get stitched multiple times
- Lazy-loaded images — anything below the fold that hasn't loaded yet shows as a blank box or broken image
- CSS scroll animations — triggered mid-capture, they produce inconsistent frames that make the final image look glitchy
- Infinite scroll pages — keep loading content as the tool scrolls, producing a runaway capture that never ends
The right approach: capture entire webpage via Chrome APIs
Chrome's tabCapture API paired with programmatic scrolling captures actual rendered pixels rather than stitching viewport snapshots. The correct sequence:
Getting screenshot fixed header scroll right
Before capturing, query every element with position: fixed or position: sticky and set visibility to hidden. Capture the full scroll. Then restore them. This one step eliminates the fixed header duplication artifact that plagues most screenshot tools.
Lazy image trick
Before the actual capture sequence, do a pre-scroll pass from top to bottom to trigger lazy-loaded images. Then scroll back to the top and wait 500ms for images to settle. This ensures nothing comes out blank.
Element and area capture
Sometimes you only need one component — a pricing card, a nav, a chart. Element capture reads the element's bounding rect and crops the full-page capture to those exact coordinates. Area capture works differently: it places a transparent overlay over the page so you can drag to define a custom crop rectangle with your mouse.
Using onHover for screenshots
Open the extension and hit Capture. You get four modes: visible area, full page, specific element, or drag-to-select area. Every captured image opens in the built-in editor where you can annotate, crop, copy to clipboard, or download directly — no intermediate files, no separate editor.
When to use each mode
- Visible area — fast bug screenshots for Slack threads or Jira tickets
- Full page — design reviews, client approvals, and documentation
- Element — isolated component shots for documentation or design handoff
- Area select — precise crop for before/after comparison screenshots
Why screenshots are core to developer communication
A bug report without a screenshot is a guess. "The button looks wrong on mobile" could mean a dozen different things — wrong color, wrong size, overlapping another element, cut off at the edge, rendering fine but in the wrong position. You don't know until you see it. The back-and-forth to establish what the reporter actually saw takes longer than fixing most bugs.
Design review has the same problem. Mockups show intent. Screenshots show reality. The gap between the two is where implementation drift hides. A designer looking at a Figma file can't see that the font weight rendered slightly wrong, or that the spacing between two components is 14px instead of 16px, or that the hover state doesn't match the spec because someone used the wrong token. A screenshot placed next to the Figma frame makes those gaps immediately obvious.
Pull request reviews are another place screenshots change the quality of feedback. If you've added a visual change — a new component state, a layout adjustment, a responsive breakpoint — reviewers without a screenshot have to check out your branch, run the project locally, and navigate to the right page to see what you're describing. Most don't. They merge on faith or ask questions that delay the review. A before/after pair in the PR description takes 30 seconds to add and removes all of that friction.
The thing that kills screenshot adoption is tool friction. If taking a screenshot requires opening a separate app, navigating through menus, waiting for a save dialog, finding the file, and then attaching it — people skip it. They describe things in words instead. The screenshot needs to be: capture, annotate if needed, paste. That's it. When the friction drops low enough, it becomes the default instead of the exception. That's the problem a Chrome extension built into your browser toolbar solves — it's already there, it's one click, and the result is on your clipboard before you've finished the thought.
High-DPI and retina display handling
Most screenshot tools capture at CSS pixels. On a MacBook with a 2x retina display, or any modern monitor running at 1.5x or 3x device pixel ratio, that means the output image is half (or a third) of the actual pixel density your screen is rendering. Open that screenshot in Figma or paste it into a Notion doc and it looks blurry — not because anything went wrong with the capture, but because the tool ignored DPR entirely.
The correct approach is to multiply capture dimensions by window.devicePixelRatio. A viewport that's 1440px wide on a 2x display should produce a 2880px-wide image. That image, when placed at 50% scale in a design tool, looks perfectly crisp.
There's a file size trade-off here. A 2x screenshot of a full page is four times the pixel count of a 1x capture — files get big fast. For sharing in Slack or Jira where file size matters, 1x is usually fine. For design handoff into Figma, for component documentation, or for anything that will be displayed at significant scale, you want 2x minimum. The onHover Chrome extension captures at native DPR by default and lets you dial it down when you need a smaller file.
Annotating before sharing
A raw screenshot is half the job. A screenshot of a broken layout tells someone something is wrong. A screenshot with a red arrow pointing to the broken element, a label reading "margin collapses at 768px breakpoint," and a box drawn around the affected area tells someone exactly what's wrong and where to look. That's the difference between a screenshot that generates more questions and one that closes the issue.
Annotation sounds like it adds time, but the right tooling makes it faster than writing a description. Here's the workflow we use with onHover's built-in annotation tools: capture the element, add an arrow pointing to the problem, drop a text label, copy the annotated result to clipboard, paste it into the Jira ticket. Start to finish, under 20 seconds. Compare that to: open screenshot, open separate annotation app, add annotations, export, find the file, attach it. The built-in path is genuinely faster.
The annotation tools that actually get used are the simple ones: arrows, rectangles, text labels, and blur for hiding sensitive data before sharing. We kept the onHover annotation layer focused on those four things. Fancy annotation tools with gradient brushes and emoji stamps don't get used in real developer workflows — they add UI weight without adding communication value.
Blur before sharing
When screenshotting pages with user data — email addresses, phone numbers, account details — use the blur annotation tool to redact before sharing. Easier than cropping and much faster than opening an image editor. Makes it safe to share screenshots in public Slack channels or external trackers without worrying about what's in the frame.
Screenshots for design handoff and documentation
Design handoff is where implementation drift becomes visible. You've built a component. The designer wants to check it against the Figma spec. The old way: they open the Figma file, check out your branch, run the app, navigate to the component, and visually compare. That process takes 10-15 minutes and requires them to have the dev environment set up.
The faster path: you capture the implemented component with the onHover element capture mode, drop it into the Figma file next to the original frame, and both of you look at the overlay. Spacing discrepancies, wrong font weights, color token mismatches — they're obvious immediately. You don't need to measure, you just see it. If something's off, you fix it before the PR merges. If everything matches, the handoff is done.
Component documentation is another area where element capture pays off. Writing a component library? Each component entry benefits from a screenshot showing actual rendered states — default, hover, disabled, error. Generated with element capture, these stay in sync with reality because you can retake them any time the component changes. No Photoshop mock, no design file to keep updated, just a screenshot of the thing actually running.
For broader documentation — user guides, internal wikis, onboarding flows — full page and area capture replace the awkward workflow of taking screenshots with system tools, cropping in Preview or Paint, and trying to maintain consistency across a document written by multiple people. One Chrome extension, consistent capture quality, annotations applied before export. The documentation looks professional without anyone making it a project.
The full set of tools relevant to design work — including screenshot capture, element inspection, and visual QA — is on the onHover for Designers page.