Show HN: ZScreenshot – Capture any viewport size without browser resize | Hacker News Reader

Show HN: ZScreenshot – Capture any viewport size without browser resize

ebot.jp

5 pointszscreenshot5 comments

Hey HN!

As a developer, I got frustrated with the screenshot workflow for documentation: Open DevTools → Set viewport size → Take screenshot → Switch tabs → Download → Open editor → Annotate → Save → Repeat...

Built ZScreenshot - a sidebar extension that keeps everything in one place. Set viewport once, capture instantly, edit in sidebar. No tab switching, no DevTools.

Free: • Custom viewport (consistent screenshot sizes, no sidebar interference) • Full-page capture (scrolling pages) • Tab recording with audio • Privacy-first (all local processing except authentication)

Pro (14-day free trial, no credit card): • Image editor (arrows, shapes, text, blur, emoji - instant annotations) • Collection (merge multiple screenshots for comparisons) • Bulk ZIP download • MP4 export

Everything happens in the sidebar: Capture → Edit → Download → Access history anytime.

Why no "select area before capture"? OS tools (Win+Shift+S, Cmd+Shift+4) already do this perfectly. ZScreenshot focuses on what they can't: viewport control, instant editing, history management. Plus, crop-after-capture gives more flexibility.

Chrome Web Store: https://chromewebstore.google.com/detail/zscreenshot/jdgmjck...

Open articleView on HN

This is a nice take on a very real workflow pain. I like the idea of fixing the viewport once and keeping capture + edit in the same context.

Curious how you handle edge cases like sticky headers, lazy-loaded content, or pages with dynamic resizing—do those affect capture accuracy?

Thanks! Good questions on the edge cases.

For full-page captures, I'm using Chrome's native DevTools screenshot API (the same one you get with Cmd+Shift+P → "Capture full size screenshot"). So the behavior for sticky headers, lazy-loaded content, and dynamic pages essentially matches what DevTools does—both the benefits and limitations.

Sticky headers: Captured in their fixed position throughout the scroll, as DevTools does.

Lazy-loaded content: Depends on how Chrome's capture handles it. Generally works well for standard lazy loading, but infinite scroll or heavily JS-dependent dynamic content can be hit-or-miss. That's a Chrome limitation rather than something I can work around in the extension.

Dynamic resizing: The viewport setting works well here since it's part of the DevTools protocol. Pages render at the specified dimensions during capture.

For visible area captures (not full-page), I have more control and it's straightforward—basically a direct screenshot of what's rendered in the viewport.

I've confirmed the bug in the full page capture feature and will fix it in the next version. Due to the Chrome Web Store review process, it will take approximately 3 days. Thank you for your feedback.

I have a similar workflow and I'd like to know how sophisticate is your requirement for annotations, because I solve that part kind of smoothly with Excalidraw

Thanks for asking! Honestly, the editor is still a work in progress. It has several features now, but there's definitely room for improvement. I'm planning to keep refining it.

The main use case I'm targeting is for people creating documentation/manuals who want to annotate screenshots on the spot without switching to another tool.

The goal is to keep everything within the same workflow - capture, annotate, and save - all in the sidebar.

I'd love it if you could give it a try and let me know what you think!

Reply on news.ycombinator.com