Security
Last updated: June 12, 2026
The short version: Snappy has no servers, no analytics, no accounts, and makes no network requests. Screenshots are captured and processed on your device. There is no backend to audit because there is no backend.
How Snappy is built
Snappy is a Chrome extension with no backend. Capturing, cropping, redacting, annotating, stamping, hashing, and exporting all run locally in your browser. Nothing is sent anywhere because there is nowhere to send it: Snappy operates no servers.
Network requests
Snappy makes none. No telemetry, no update pings, no font or analytics CDNs. All code runs from the extension package; nothing is loaded remotely. You can confirm this with the Network tab in DevTools.
If a future opt-in feature needs the network (the roadmap below has two candidates), it will be off by default and documented in the privacy policy and the Chrome Web Store listing before it ships. Capturing itself will never make a network request.
Permissions
Snappy requests no host permissions and no
<all_urls> access, so it cannot read pages in the
background and cannot see your browsing history. Here is the full
list from the manifest.
| Permission | Why it's needed | What it cannot do |
|---|---|---|
activeTab |
Grants access to the current tab only at the moment you trigger a capture or open the live editor, so the visible tab can be captured. | Cannot access any tab you didn't act on, and cannot see your browsing history. Access expires when you navigate away. |
scripting |
Shows the post-capture quick-actions card, performs full-page auto-scroll, and opens the on-page live editor, only on the tab you explicitly acted on. | Cannot inject into tabs you didn't capture or invoke the live editor on. No background injection. |
storage |
Stores your editor preferences and holds the most recent capture so the editor can display it. | Nothing is transmitted; storage is local to your browser. |
unlimitedStorage |
Lets the optional, off-by-default gallery hold full-resolution captures locally (IndexedDB) without hitting quota limits. | Used only on your device. Nothing is uploaded. The gallery is opt-in and you can clear it anytime. |
contextMenus |
Adds navigation items to the toolbar icon's right-click menu, plus one page item ("Snappy: edit this page live") that opens the live editor on the current tab. |
The menu item reads nothing from the page; clicking it grants
activeTab for that one tab, same as the shortcut.
|
identity, identity.email |
Reads your browser profile's Google account email, locally and only when you click Verify in Evidence settings, so stamps can carry a verified "captured by". | No OAuth flow, no token, no network request, no account access beyond the email string. The email is never transmitted by Snappy. |
Where your data lives
- Captures: processed in memory and written to your clipboard or Downloads folder when you export. By default only the most recent capture is held in local storage so the editor can open it.
- Gallery (opt-in): recent captures stored locally in IndexedDB, on your device only, never uploaded.
-
Settings: preferences and the "captured by" value
live in
chrome.storage.localand stay on your device. - Live redactions: when you capture from the live editor, hidden regions are baked into the pixels, and the covered text is also removed from the page text Snappy stores with the capture, so a redacted secret can't resurface through gallery search or pick & pull.
What the evidence fingerprint proves
Evidence mode can attach a SHA-256 fingerprint of the image to a
.evidence.json manifest, and the
verifier page recomputes it in your browser.
- A match proves the image hasn't been altered, re-saved, or corrupted since the manifest was written. Even a one-pixel change breaks it. This catches accidental edits, format re-encodes, and anyone who edits the image without updating the manifest.
- A match cannot prove who created the bundle. The manifest is plain JSON. Someone determined to fake evidence can edit an image, recompute its hash, and write a new manifest that matches. The recorded tool, time, and URL are records, not cryptographic proof. This limitation applies to any tool that runs entirely on the user's own machine, and we think it should be stated rather than glossed over.
The way to close that gap today is custody: when a capture matters, record its fingerprint somewhere the holder of the image can't edit later, like the audit ticket or an email to the auditor. The verifier page explains this in more detail.
On the roadmap
Two planned features strengthen evidence integrity further. Both will be opt-in and off by default, and neither changes how capturing works.
- Trusted timestamping. Send the 64-character hash (never the image) to an RFC 3161 timestamp authority and store the signed token in the bundle. An independent third party then attests that this exact fingerprint existed at a given time, so a forged bundle can't be backdated.
- Cloud delivery. Optionally send evidence bundles to your own Drive or SharePoint folder at capture time. The bundle lands somewhere with its own timestamps and access controls, which gives you custody without any new infrastructure to trust.
Reporting an issue
Found a security concern? Reach out through the Chrome Web Store listing's support tab.