Launching today

ZumiLabs OmniCapt

Launching today

Capture one page or your whole site. All local. All private

5 followers

Capture one page or your whole site. All local. All private

5 followers

Visit website

Most screenshot extensions upload to a cloud and capture one page at a time. OmniCapt is 100% local and captures at scale: paste a URL list or sitemap and it shoots every page at every breakpoint (50 URLs × 3 sizes = 150 shots), auto-sorted into folders by domain/path/date. Every capture gets a JSON sidecar of scraped page metadata, so your library is searchable, and the file browser compares any two shots side-by-side or with a slider-wipe. Plus annotation & WebM recording. Nothing uploaded.

Free

Launch tags:Chrome Extensions•Productivity•Developer Tools

Launch Team

ElevenAgents by ElevenLabsScale conversations without scaling your team

Promoted

Maker

📌

Hey Product Hunt — I'm Amith, the builder behind ZumiLabs, and today I'm launching OmniCapt. I built it to scratch a real itch: I needed to capture lots of screenshots for a site being developed, at different resolutions, across many pages on my sites — to check responsive designs both on my local machine and on internal test servers. Doing that by hand (resize, screenshot, repeat, for every page and every breakpoint) was painful. But the tools that promised to automate it mostly run as hosted crawlers — they need your site reachable from the public internet, so capturing internal or pre-prod environments would've meant poking holes in firewalls or whitelisting IPs just to take a screenshot. That's a security and privacy trade-off I wasn't willing to make, so I needed something fully local. And browser capture extensions weren't much better: many are really front-ends for a cloud service that upload your screen, make you sign in, and add a delay to something I do dozens of times a day or only save the image to the downloads folder without any control over naming convention. So I built OmniCapt to do all the work in the browser. Nothing you capture leaves your machine. A lot of it evolved by hitting walls. "Capture every open tab" started by just activating each tab and screenshotting it — until I realised activating a tab is a focus change that closes the extension popup and kills the File System Access handle, so nothing saved; that's why it now uses Chrome's DevTools Protocol to shoot tabs in place instead. Saving started on chrome.downloads too, but a 150-file batch means 150 download prompts — unusable — so it moved to the File System Access API with a single folder grant. And the biggest shift was positioning: I built it as a one-page screenshot tool, then realised the part nobody else did well — bulk, multi-resolution, entirely local — was the actual point. So I leaned the whole thing into "capture one page, or your whole site." What makes it different: Every screenshot mode — visible, region, and full-page scroll-and-stitch (everything below the fold, one click). Capture at scale is the part most tools don't do. Paste a list of URLs (or import a sitemap) and it visits and screenshots every one, unattended — one file per page. Or capture every tab you already have open, by window or tab group, without ever switching focus (it uses Chrome's DevTools Protocol to shoot each tab in place). Queue up a URL set and walk away. Then multiply that by every resolution — define Desktop/Tablet/Mobile once and it captures each page at every size, auto-named with width×height. A 50-URL set across 3 breakpoints is 150 screenshots from one click. This is the responsive-QA feature I built it for. Everything saves straight to a local folder (File System Access API) with no download prompts, using a filename structure you define: slashes auto-create sub-folders, so captures sort themselves by domain, path, date, or even metadata scraped from the page (e.g. {{domain}}/{{path}}/{{year}}/{{dom:h1}}.png). Each one can carry a JSON sidecar with the page's URL, title, resolution, timestamp and scraped metadata (description, keywords, author, OG tags), so your captures are self-documenting and searchable. That searchability pays off in the built-in file browser. Browse every capture as thumbnails inside Chrome, filter across all that metadata to find any shot in seconds, then pick any two and compare them side-by-side or with a slider-wipe overlay to spot what changed between two runs — without leaving the browser. It also records your tab to WebM (tab audio, mic, on-screen timer, click ripples, pause/mute, and a built-in clip merger), and lets you annotate a page — arrows, boxes, text, full undo/redo — before you capture. It's local-first by design: no server, no account, no telemetry — open your network tab and nothing leaves. There's an optional CloudSend hook to push selected captures to Jira, Slack, GitHub, Confluence, Miro, S3, Google Drive or Contentful, but it stays hidden until you set it up, your token lives only in your browser, and the only time anything is uploaded is if you turn it on and point it at your own endpoint. (A hosted ZumiLabs backend is coming soon — early access on request.) It's free on the Chrome Web Store. It's part of a broader push at ZumiLabs to build fast, local-first browser utilities that just work. I'd genuinely love feedback on the workflow, and to hear what capture pain points you'd want solved next.

Report

1d ago

Curious how the metadata scraping actually works under the hood — is it pulling from the rendered DOM, structured data, or something custom, and can I customize which fields end up in that JSON sidecar? Also wondering about the limits when a site lazy-loads basically everything.

Report

3h ago

Maker

@helinbxw5

Thank you for taking a look. These are great questions.

Regarding Metadata Scraping:

It’s a custom client-side script running on the rendered DOM. When you take a capture, our injected content script queries the DOM for standard metadata.

- Tags: It pulls and sanitizes tags by combining `meta[name="keywords"]` (and news keywords) with all `meta[property="article:tag"]` elements.

- Structured Meta: It grabs Open Graph data (`og:title`, `og:description`, `og:image`, `og:type`), canonical URLs, and the page author.

- Runtime Context: It attaches runtime metadata like the tab's current URL, title, exact capture timestamp, and the viewport resolution.

Regarding :Sidecar Customization

Right now, you can toggle the JSON sidecar generation on or off in the Settings. The fields themselves are predefined. However, since the extension already features a robust token-resolution system for customizing filenames (using tokens like `{{domain}}`, `{{date}}`, `{{time}}`, etc.), adding custom JSON templates or field toggles is definitely something I can consider and shouldn't be too hard to implement

Regarding Handling Lazy-Loaded Content

For full-page captures, we use a scroll-and-stitch pipeline. Here's how it manages lazy-loaders:

- It forces instant scrolling (`scroll-behavior: auto !important`) to disable smooth transitions.

- It scrolls the page down in viewport-sized increments.

- It inserts a 600ms delay at each scroll step before capturing. While this is primarily to avoid triggering Chrome's API limits on tab captures per second, it serves as a reliable buffer allowing images and viewport-triggered scripts to load.

- If a site has infinite scroll, you can hit the "Stop & Save Now" button in the popup at any time to instantly stop scrolling and stitch what has been captured up to that point.

I hope that addresses your questions, let me know if you have any more, and thanks very much for taking the time to comment.

Report

3h ago

The sitemap batch capture is genuinely useful, and being able to wipe between breakpoints right in the file browser saved me from jumping tabs. Nice touch with the JSON sidecar for searching across a huge library.

Report

3h ago

Maker

Hi @nuriyetarkay
Thank you so much for taking the time to have a look, I really appreciate it.

That exact pain point - getting lost in a sea of Finder/Explorer files and constantly jumping between tabs to spot layout shifts - is why we built the built-in file browser and the slider-wipe tool.

Using the companion JSON sidecars was another deliberate choice: keeping all the metadata local, lightweight, and offline-friendly means searching through thousands of captures is instant, and it makes it super easy to script or grep your library if you want to integrate it with other tools.

Thanks again, and do let me know if there are other features of interest

Report

3h ago