Private screenshot tools: on-device vs cloud capture, compared

Nobody shops for a screenshot tool by its network architecture. You pick one for the toolbar, the hotkey, the share link. But the architecture is the only part that decides whether an image of your bank balance, your unreleased design, or your private conversation ever leaves the device it was captured on. This article is about learning to see that architecture — and about being honest that both kinds have real advantages.

Two architectures hiding behind one button

Every capture tool is either on-device — the pixels are rendered, annotated, and saved entirely on your machine — or cloud — some part of that pipeline runs on, or passes through, a server the vendor controls. The cloud version isn't inherently evil; it's how share-by-link works, how cross-device sync works, and increasingly how heavy full-page stitching and AI features work. The point isn't to avoid the cloud on principle. It's to know which one you're holding before you point it at something sensitive.

What cloud capture actually does — and why it's tempting

Cloud capture earns its keep in four places. Share links: the moment a tool offers “copy link to screenshot,” your image is on a server — that's what the link points at. Cross-device sync: capture on your laptop, see it on your phone; that's a server in the middle. Server-side stitching: some full-page tools upload page fragments and assemble the tall image remotely. AI features: OCR, summarisation, “clean up this screenshot” — the model usually lives in the cloud, so your image travels to it.

Each of those is genuinely useful. Each also means the frame you captured — possibly with a password field, a customer record, or an internal URL in it — now exists on infrastructure you don't control, subject to a retention policy you probably haven't read. Lightshot's entire appeal was the first item on that list, and it's a big part of why its 2024 shutdown left people uneasy; we covered the specifics in the Lightshot alternative breakdown.

What on-device capture costs you — and what it buys

On-device tools give up convenience. There's no instant public link, no automatic sync to your other devices, and — because there's no big server budget behind an AI pipeline — fewer flashy smart features. What you get in exchange is a hard guarantee: the image is never transmitted, so it can't be intercepted, retained, subpoenaed, or leaked from a vendor you trusted. For a screenshot of anything you wouldn't want on the evening news, that trade is usually worth making. It's the whole premise of our private redaction workflow — redaction is pointless if the un-redacted original already went to a server.

How to tell which one you're using

1. Read the permission list

   For a Chrome extension, open chrome://extensions and check what it can access. A tool that declares zero host_permissions cannot make network calls to arbitrary sites — Chrome blocks them. That's enforcement, not a promise.

2. Watch the network panel

   Open DevTools' Network tab, take a capture, and see what fires. A request carrying image data to a vendor domain tells you everything the marketing page didn't.

3. Look for the tell-tale features

   “Copy share link,” “sync to my devices,” cloud history, and AI cleanup all imply a server. Their absence is weak evidence of on-device; their presence is strong evidence of cloud.

4. Check whether an account is required

   If you had to sign in to take a screenshot, something about your usage — at minimum your identity — is being recorded remotely.

The capability trade-off, side by side

Where the popular tools actually land

Most tools aren't purely one or the other, which is what makes this confusing. Here's the honest map, each with its own deep-dive:

• Lightshot — cloud. Its share-link flow uploaded captures to public, guessable URLs, and development stopped in 2024. See the Lightshot alternative page.
• GoFullPage — cloud-assisted. Sharing and some capture flows route through its servers, and it was removed from the Chrome Web Store in 2026. See the GoFullPage alternative page.
• Greenshot — on-device by default, but it ships optional upload destinations you can wire in. Free and open source, Windows-first. See the Greenshot alternative page.
• ShareX — on-device capture with a configurable after-capture pipeline that often uploads unless you turn it off. Enormously capable, Windows-only. See the ShareX alternative page.

Where the Snap family sits — and why

SnapLocal and SnapPage are deliberately, verifiably on-device. Both are Chrome extensions that declare zero host_permissions and contain no remote code, so there is no path that could upload a capture — Chrome enforces that. SnapLocal handles region capture and true pixel-destructive mosaic redaction; SnapPage stitches full scrolling pages locally, which is the one place most people assume a server must be involved and, here, none is. Neither needs an account. Both are free to use, with one-time Pro buyouts ($19 and $15) instead of subscriptions. If you want the wider field graded on this exact axis, see Privacy-First Screenshot Tools in 2026.

The pragmatic middle path

You don't have to pick one tool for life. A sensible split: use a cloud tool when you genuinely need a share link for something public and harmless — a meme, a public webpage, a design you're allowed to show. Use an on-device tool the moment the frame might contain a secret. The mistake isn't using the cloud; it's using a cloud tool by default and only realising, later, that the one capture with a password in it went to a server too.