Extenshiextenshi.io/blog
Back to articles
extension reviewsdeveloper toolsprivacypermissionsbrowser extensions

Developer extensions reviewed: what Wappalyzer, JSON Formatter, ColorZilla and four others send home

I unpacked the current builds of seven developer extensions, from Wappalyzer to React DevTools, and traced what each one reads and sends off your machine.

Maxim Kosterin
12 min read
Four thin line-drawn instruments — a prism, angle brackets, a droplet and a branching node — each connected by a hairline into one large watercolour orange window
Four thin line-drawn instruments — a prism, angle brackets, a droplet and a branching node — each connected by a hairline into one large watercolour orange window

I spend my week looking at what other people's extensions can reach. Then I open my own browser, where a tech profiler, a JSON viewer, a colour picker and a React panel have sat on "read and change all your data on all websites" since forever. I installed them for work and never thought about it again.

Developer extensions get a free pass. Few people stop to ask "is Wappalyzer safe?", because the people who install it are supposed to already know.

So this time I didn't take anyone's word for it. On October 16, 2026 I downloaded the current Chrome Web Store build of seven developer extensions, read each manifest and followed every network call in the shipped code. One question: what does this thing see, and what leaves your machine?

Quick verdict

  • Wappalyzer reads every page and, in the Chrome build, reports the sites you visit back to Wappalyzer by default. There's a toggle.
  • WhatRuns sends the address of nearly every page you load to its own server.
  • BuiltWith Technology Profiler can't read pages; it sends the tab's address when you click.
  • JSON Formatter runs on every URL and sends nothing, but its public repo lags the store build.
  • ColorZilla holds every site and sends nothing. Eye Dropper does the same job with just the tab you click.
  • React Developer Tools needs every page; its two outbound calls serve the panel itself.
  • My take: the permission string tells you almost nothing. The code does.

Why most of them ask for your whole browser

A dev extension has to look at the page, and the bluntest way to get that in Chrome's permission model is to ask for every site. Five of these seven do, and Chrome gives them all the same install warning, "Read and change all your data on all websites". Long version: what that permission actually buys an extension.

The narrower routes are activeTab, which grants only the tab you click, or no page access at all. Two of the seven take one of them.

Tech profilers: three ways to answer "what is this site built on?"

Is Wappalyzer safe? It detects locally and reports in batches

Wappalyzer (3,000,000 users, version 6.12.7) runs a content script on every http and https page and detects technologies locally, against a database shipped inside the extension.

The reporting is in the code too. In batches of up to 25, the background worker posts the hostnames you visited, the technologies found on each and the page language to ping.wappalyzer.com. Full URLs and page content aren't included, which matches Wappalyzer's privacy policy. The policy adds that this data can be shared or sold as part of Wappalyzer's products.

In the Chrome build sharing is on from the start: the code treats the terms as accepted on Chrome, while Firefox gets the browser's own consent prompt. Hostnames that look local or pre-production (localhost, raw IPs, staging., dev., .test) are filtered out. Production domains still go, and for a contractor that's a list of current clients.

What I do: open the settings and switch off Anonymously send identified technologies to wappalyzer.com. Detection keeps working locally.

WhatRuns: sends the address, detects on the server

WhatRuns (400,000 users, version 1.10.0) works the other way round. For every page that loads in a tab, its background worker posts the address, minus the query string, to whatruns.com/api/v1/get_site_apps, and the server answers with the technologies. It skips localhost and eight big domains such as Google and YouTube. Staging hosts go too, and no click is needed.

If you sign in to a WhatRuns account, the same request also carries your account email and API key, base64-encoded. The WhatRuns privacy policy says collected data is "never linked to identifiable users or personal browsing histories", and the store listing declares "Website content".

What I do: I don't run it, and I'd never run it signed in on a work profile.

BuiltWith: no page access, one request per click

BuiltWith Technology Profiler (300,000 users, version 3.6) asks only for tabs and for https://builtwith.com/. It can't read a single page. When you click it, it takes the current tab's address and asks builtwith.com what it knows about that site.

That's the narrowest model of the three, with two costs: it sends the full address, query string included, so a ?token= goes too. And the build hasn't been updated since May 11, 2022.

What I do: for a quick "what is this built on", Wappalyzer with sharing off or BuiltWith clicked on public pages. WhatRuns sends the most for the same answer.

Colour pickers: same job, two access models

ColorZilla (4,000,000 users, version 4.1, last updated May 22, 2024) holds access to every site. Its shipped code calls no one: the fetches load files bundled with the extension, and both the listing and its privacy page say it collects no data.

Eye Dropper (1,000,000 users, version 4.10.3.17) does the same job with activeTab, so there's no all-your-data warning at install, and its code calls no one either. It does open a partner page on extensions-hub.com after install and sets that site as its uninstall page. Visible, not silent.

So ColorZilla isn't sending your data. The question is why a colour picker should hold standing access to your email tab when one with a million users manages without it. The Chrome DevTools colour picker has an eyedropper too.

What I do: Eye Dropper or DevTools. If you keep ColorZilla, set its site access to on click.

JSON Formatter: tiny tool, enormous window

A JSON viewer's job is "if this tab happens to be JSON, make it readable". Any URL might return JSON, so the popular JSON Formatter (2,000,000 users, version 0.10.2) puts a content script on every URL.

Think about what you open in a raw tab: internal API responses, webhook payloads, a staging endpoint with a ?token= still attached. The current build sends none of it anywhere. What I care about is how fast that can change.

In January, v0.9 added Give Freely, a charity-affiliate popup for shopping sites; the author removed it a week later. In February the README marked the repo archived, with the project moving to a closed-source, commercial model. That notice came down in September, but the repo still stops at 0.9.4. The code you can read isn't the code you run, which is exactly when an update quietly changes what an extension does.

What I do: use the browser's own viewer. Chrome puts a Pretty-print checkbox on raw JSON tabs, and Firefox has a built-in JSON viewer.

React Developer Tools: open source, two outbound calls

Meta's React panel (5,000,000 users, version 8.0.0) has to spot React on any page, so it injects a hook into every one. It's open source, and the store listing names the source revision each build came from.

The shipped code reaches the network in two places. To show hook names, it re-downloads the scripts the inspected page already loaded. When the panel itself crashes, it searches GitHub's public issue API with the error message, so it can point you at an existing report. Neither call goes to Meta.

The paperwork lags the code: in 2020 someone asked on the React repo why it had no privacy policy, and the answer was one line on the listing. The listing now declares that it collects no data.

What I do: keep it, in a browser profile I only use for development.

What each one reads and sends

All figures are from the Chrome Web Store builds and listings as of October 16, 2026.

Extension Version (updated) Page access What the shipped code sends Store privacy label
Wappalyzer 6.12.7 (Sep 29, 2026) Every http/https page Visited hostnames + detected technologies to Wappalyzer, on by default in Chrome Website content
WhatRuns 1.10.0 (Apr 27, 2026) Every site Address of each page you load, minus the query string, staging hosts included; account email and API key if signed in Website content
BuiltWith 3.6 (May 11, 2022) None; only the tab's address The full tab address, on click Personally identifiable information
JSON Formatter 0.10.2 (May 16, 2026) Every URL Nothing found Doesn't collect
ColorZilla 4.1 (May 22, 2024) Every site Nothing found Doesn't collect
Eye Dropper 4.10.3.17 (Jul 15, 2026) The tab you click Nothing found; opens a partner page on install Doesn't collect
React DevTools 8.0.0 (Sep 11, 2026) Every page Re-fetches the inspected page's own scripts; a GitHub issue search on a crash Doesn't collect

"Nothing found" means I read the code and found no call that sends data off the device. It's a statement about one version, and the next update can change it.

The one that actually gets you: keys in a settings box

In January, Obsidian Security documented a Chrome extension impersonating ChatGPT — first ChatGPT Extension, later H-Chat Assistant — that asked users for an OpenAI API key. The researchers say it worked as advertised and sent the key to a Telegram chat through a hard-coded bot. They put it at roughly 10,000 installs and recovered 459 unique keys, which they handed to OpenAI. The listing is gone from the Chrome Web Store now.

The same play hit JetBrains Marketplace in June. Aikido Security found 15 plugins that worked as AI coding helpers while sending the keys developers saved in their settings to a hard-coded server, close to 70,000 installs combined, BleepingComputer reported. JetBrains removed the plugins and disabled them in installed IDEs.

Neither attack needed a clever permission, only a credential typed into someone else's code: the same trust collapse as fake AI extensions harvesting credentials.

Rule I'd make non-negotiable: a provider API key never goes into a browser extension's settings. If a tool needs your key, it gets it through a backend you control, or it does without.

Five minutes, this afternoon

  1. Open chrome://extensions, hit Details on each dev tool and set Site access to On click.
  2. Where a narrower tool does the same job, switch: Eye Dropper for ColorZilla, the browser's own JSON viewer for an extension, Wappalyzer with sharing off for WhatRuns.
  3. Move dev extensions to a separate browser profile. Then the blast radius is your dev profile, not your bank.
  4. Rotate any provider API key you have ever pasted into an extension.
  5. Inventory what you've got. npx @extenshi/guard list prints every extension installed across your browsers, no account needed. npx @extenshi/guard scan checks the ones you installed from a store against the Extenshi catalog and walks you through disabling or removing the flagged ones, with undo (free account required, docs). Unpacked builds are listed, not analyzed.
  6. Recheck the ones you installed years ago: an extension nobody maintains is a listing waiting for a new owner.

Final recommendation

Keep the tools you need, but treat "developer extension" as a description of the audience, not a security property. The difference lives in the code, the privacy label and whether you left site access wide open. Where a narrower tool does the job, use it.

And if one of your dev tools ever asks for a credential, close the tab.

Check an extension → Paste any store URL to see its permissions and publisher before you install it.

Methodology

On October 16, 2026 I downloaded each extension's current package from the Chrome Web Store, read its manifest.json, searched the shipped JavaScript for every network API (fetch, XMLHttpRequest, sendBeacon, WebSocket) and followed each call to its destination and payload. Version, update date, user count and privacy label come from each listing on the same day. It's a static read of one version, not a traffic capture, and it can't see what a server does with what it receives.

Sources

This article is based on our own static reading of publicly distributed extension packages, vendor documentation, store listings, security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers or vendors. Descriptions of Wappalyzer, WhatRuns, BuiltWith Technology Profiler, JSON Formatter, ColorZilla, Eye Dropper and React Developer Tools reflect those projects' own published policies, repositories, store listings and Chrome Web Store builds as of October 16, 2026, and do not constitute accusations of intentional wrongdoing. None of the vendors named here were contacted for comment prior to publication, and no public response specific to this article exists. If any entity referenced believes information is inaccurate, contact [email protected] and we will review and update.

Related Articles