HeaderSnap Collects Zero Data From Your Browser

When developers search for a Chrome extension that doesn’t track them, the standard answer is vague: “we respect your privacy,” backed by a privacy policy few people read. This post is different. Here’s exactly what HeaderSnap stores, where it stores it, and what you can verify for yourself.

Short version: HeaderSnap collects nothing. No analytics, no telemetry, no external server calls. Everything stays in your browser — and here’s how to confirm that independently.

What HeaderSnap Stores and Where

HeaderSnap stores three things: your header rules, your profiles, and your settings. All three go into chrome.storage.sync — Chrome’s built-in storage API that syncs your data across your own devices via Google’s infrastructure. This is the same mechanism that syncs your Chrome bookmarks.

The critical distinction: chrome.storage.sync is managed by Google, not by HeaderSnap. The HeaderSnap developer has no servers that receive this data, no access to it, and no way to read it. When you create a rule in HeaderSnap, that rule goes into Chrome, and Chrome handles the rest. If you’re signed into Chrome, Google syncs it to your other Chrome devices. If you’re not, it stays on that machine.

This storage does not send any data to a third-party server. It requires no account and is not accessible to HeaderSnap’s developers.

What HeaderSnap’s Permissions Actually Mean

HeaderSnap requests the following permissions:

declarativeNetRequest — apply your header modification rules
declarativeNetRequestWithHostAccess — apply those rules to URLs you specify
storage — read and write your rules to Chrome’s built-in storage
host_permissions: <all_urls> — let your rules apply to any URL you configure

What’s not in that list: tabs, cookies, webRequest. HeaderSnap cannot inspect page content, read cookies, or intercept request bodies. It can only apply the specific header modifications you’ve defined — nothing else.

The declarativeNetRequest architecture matters beyond just permissions. With the older webRequest API (which many extensions still use), request data passes through JavaScript code running in the extension. With declarativeNetRequest, you give Chrome a set of declarative rules, and Chrome’s browser engine applies them directly. The extension code doesn’t sit between your browser and your requests.

How to Verify This Yourself

Open Chrome DevTools, go to the Network tab, and filter by XHR and Fetch. Use HeaderSnap for a few minutes — set a header, toggle a profile, load some pages. You’ll see the network requests your pages make. You will not see requests from HeaderSnap.

What you can specifically look for:

No analytics calls — no requests to Google Analytics, Mixpanel, Segment, Amplitude, or similar endpoints
No license checks — no outbound requests on install or startup to verify anything with a remote server
No developer callbacks — no requests to headersnap.com or any other developer-controlled endpoint

Why This Comes Up Now

The ShotBird malware incident put extension supply chain attacks back in focus. The attack followed a well-documented playbook: acquire a trusted extension, push a malicious update, exploit the existing trust and permissions. This kind of attack requires an extension that can communicate with external servers — that’s how the command-and-control channel works, and how data exfiltration works. Separately, CVE-2026-0628 highlighted how a malicious extension can exploit browser-level vulnerabilities to escalate privileges — a different but related category of risk.

An extension that makes no external network calls has no mechanism for this pattern. There’s no remote server to redirect after an ownership change. There’s no analytics pipeline to start sending data elsewhere. The extension does what it does locally, and that behavior can’t change remotely.

This is the concrete value of minimal footprint, beyond the general principle: it limits attack surface in a way that is independently verifiable, right now, without trusting documentation or reputation.

HeaderSnap vs. ModHeader

ModHeader has over 800,000 installs and is the default choice for most developers who need to modify headers in Chrome. Community reviews have raised concerns about unexpected advertising behavior in ModHeader, including users flagging unwanted tab openings and similar issues — if you search Chrome Web Store reviews, you can verify these reports yourself.

HeaderSnap was built as a direct alternative with an explicit design constraint: no developer-controlled infrastructure. No accounts, no cloud sync to our servers, no analytics. The feature set covers everything most developers need — header rules with URL pattern matching, multiple profiles, import from ModHeader — without the overhead of a cloud service.

The Short Version

HeaderSnap is a header editor. It modifies the HTTP headers you configure. That’s what it does.

It doesn’t call home. It doesn’t track usage. It doesn’t sync to any developer server. Your rules live in Chrome, applied by Chrome, deleted from Chrome when you uninstall it.

If you want a header editor you can actually verify — not just one that claims to be private — learn more about HeaderSnap.