FMHY SafeGuard: a browser extension that labels sites from the FMHY filterlists

A verdict on the current tab, drawn from community lists

FMHY SafeGuard is a browser extension that checks websites against the latest filterlists from FMHY Filterlist, and categorises them as starred, safe, unsafe or potentially unsafe.

The mechanism is a lookup rather than an analysis. The extension asks the upstream FMHY services whether the domain is known, and paints the answer into the toolbar icon, the pop-up and, where applicable, the search results page. The five states are visible in the project's own icon table: not in the wiki, starred, safe, potentially unsafe, and unsafe. A site the lists have never heard of is not a safe verdict, it is an absence of one, and the extension shows it as such.

That distinction is the single most important thing to understand about the tool, and the documentation's own wording points at it. The extension is described as keeping you safe by checking websites against the filterlists, and as offering protection from the latest unsafe domains, but the mechanism is a list membership test. A domain that is malicious, new, and not yet added to a community list will come back as not in the wiki.

The audience is therefore narrower than the wording suggests. It is for people who already treat the FMHY wiki and its filterlists as a reference, and who want the lookup to happen automatically while they browse.

Four upstream services, four different questions

The credits section is the most informative part of the README, because it maps each verdict to a different upstream service.

FMHY Filterlist is the service used to detect unsafe and potentially unsafe sites. FMHY Bookmarks is the service used to detect starred sites, which is the category for the entries the wiki highlights. FMHY Edit is the service used to detect safe sites, the ones the wiki has looked at and signed off on. And the FMHY Related Sites and Projects List, the fmhy-filterlist.txt file in the repository, is the service used to detect sites and projects related to the wiki.

So the four labels come from four different sources, which is worth keeping in mind when a site shows as starred rather than safe. Starred means it is in the bookmarks list, and the documentation does not claim the two lists carry the same meaning.

The original creator is credited as Kenneth Hendricks, and the services themselves are credited to FMHY. The repository ships the related sites list as a plain text file, alongside an updates.json, which is presumably the mechanism for telling the extension that a new list version exists.

For anyone reading the code, the layout is clear: src/ holds the extension code with a js/ and pub/ split, platform/ holds the browser specific parts, tools/ holds the build and check scripts, tests/ holds the test suite, test-builds/ holds build outputs, and docs/ holds the documentation site.

Beyond the verdict: reasons, notes, passwords and search result colouring

The feature list is where this stops being a lookup box and becomes a browsing companion.

Real-time site status gives instant feedback with toolbar icons, and pop-up alerts present the status in readable form with the option to act. Unsafe site reasons show exactly why a site was flagged, with detailed reasons and clickable evidence links, which is the difference between a warning you can dismiss and one you can act on.

FMHY Notes shows relevant notes from the wiki when you visit a mapped website, with more than 80 domain mappings. That is a curated subset, so notes are not available everywhere, and the coverage is the part to keep in mind.

Site passwords and invite codes are displayed automatically for sites that need them, with click-to-copy, which saves the archaeology of finding a code on a wiki page you would otherwise have to search for.

Search engine focused highlighting colours links on search results pages so a dangerous result is visible before you click it, and the documentation is careful about the edge case: potentially unsafe sites are handled by the toolbar, the pop-up and the warning page, not by the search result highlighting.

The presentation side is also handled: the interface is available in 7 languages, English, Spanish, Russian, German, Portuguese, French and Japanese, and there are dark, light and AMOLED themes with detection of the system preference. Settings cover the theme, the filtered site count, warning page toggles and the filter update frequency.

Three ways to install it, and what to set afterwards

The extension is distributed in three places, and the documentation links all of them: the releases page on GitHub, the Firefox add-on page, and the Chrome Web Store listing.

Installing from the releases page gives you the build artefact directly. The store listings are the path most people will take, and the difference between them is the review and update cycle of the store rather than the code.

The three usage steps in the documentation are short. Install the extension from one of those three places. Browse, and the toolbar icon updates automatically to reflect the site status, one of starred, safe, unsafe or potentially unsafe. Then click the extension icon to open a pop-up with detailed site status information, including a link to contribute or report unknown sites, and that link is marked as coming soon.

The customisation step comes after that, and the settings list in the documentation is worth reading before you install: theme, filtered site count, warning page toggles and filter update frequency. The update frequency matters most, because it decides how quickly a newly added unsafe domain is reflected in your browser, and a community list that is updated daily and one that is refreshed weekly are very different guarantees.

One caveat on the first run: the extension needs the upstream services to be reachable, and a first lookup is a network round trip to those services rather than a local computation.

The local toolchain is npm scripts and the Node test runner

For anyone who wants to work on the extension, the repository documents the layout and the commands in CONTRIBUTING.md.

The scripts in the package manifest are the whole workflow. The test script runs the Node test runner over the test files with node --test tests/*.test.js. There is a check script, node tools/check.mjs, and a separate check:firefox script, node tools/check-firefox-compatibility.mjs, which is the interesting one because the extension targets two browsers with different extension APIs and a compatibility check is exactly what you would want in the loop. The build is node tools/build.mjs, and a build:test variant passes --test-builds to produce the artefacts under the test-builds/ directory. The verify script chains the lot: npm run lint && npm run check && npm test && npm run build.

Linting is eslint over src, docs/script.js, tests, tools and the eslint config itself, and formatting is prettier over the JavaScript and MJS sources. The dev dependencies are correspondingly light: eslint with its recommended config, prettier, jsdom for the DOM environment in tests, and globals.

The engine requirement in the manifest is specific. It accepts node ^22.22.2 or ^24.15.0 or 26.0.0 and above, which is a narrow but modern range, and it means a contributor on an older long term support release of Node will not be able to run the toolchain as it stands.

The package itself is marked private, so this is an application that is built and released rather than a library you would depend on from npm.

What the extension will not tell you, and when to use something else

The honest limits come from the design, and they are worth stating before you install it.

The first is that a verdict is a list membership test, so an unlisted domain reads as unknown, not as safe. For a reader who is already careful, that is a useful default. For somebody who wants the extension to be a shield, it is the wrong model, and a blocking filter list is the tool for that job.

The second is that the lists are community maintained, which cuts both ways. They are the same lists the wiki is built from, so they are as current as the wiki is, and an entry that is wrong or stale is a wrong or stale verdict in your toolbar. The unsafe site reasons feature exists precisely to make those judgements auditable, with clickable evidence links, and that is where you should look before you trust or dismiss a flag.

The third is coverage. FMHY Notes need a domain mapping, and there are more than 80 of them, so most sites will not have notes. The seven interface languages cover the major European ones plus Japanese, but the interface language and the wiki content language are not the same thing.

And the fourth is the awkward one. The site passwords and invite codes feature surfaces credentials for sites you may need to sign up for, which is convenient and also means the extension is handling secrets, a matter of trust in the extension and the browser profile. That is a decision about trust in the extension and the browser profile, not a technical limitation, and it belongs to whoever installs it.

Maintenance, licence and the pace of releases

The project is not archived, the last push was on 2026-10-02, and the release history shows steady work: v1.4.5 on 2026-10-02, v1.4.4 on 2026-09-21 and v1.4.3 on 2026-09-20. There is a CHANGELOG.md for the detail, a RELEASE.HEAD.md file for the release notes, and a Discord invite linked from the header for questions.

The licence is GPL-3.0, which is a different choice from most browser extensions, and it is worth understanding why it is visible in the repository rather than buried. The extension is distributed through the Firefox add-on site and the Chrome Web Store as well as through GitHub releases, and a copyleft licence on a distributed binary has obligations that a permissive one does not. The licence file in the repository is the text to read, and this is not legal advice.

The dependency picture is refreshingly plain. The manifest has no runtime dependencies at all, only dev dependencies for linting, formatting and the DOM test environment, so the extension itself ships without a third party code base inside it. The external data it relies on is fetched at run time from the FMHY services, which is the same thing that makes the filterlists current, and also the same thing that means the extension cannot answer anything while those services are unreachable.

The extension is described as free and open source, fully customizable and open to community contributions, and the contribution route is a pull request on GitHub.

Editorial conclusion

Adopt FMHY SafeGuard if you already rely on the FMHY lists and want the verdict, the reasons and the site passwords on the page you are reading rather than in another tab. Do not adopt it as a security control you rely on, because the extension reports what the community lists contain and leaves a site that is not listed as unknown rather than unsafe. Verify first which FMHY services the extension is configured to query, how often it refreshes the filterlists, and that the seven available interface languages and the dark, light or AMOLED themes match what you need.

Frequently asked questions

Official sources

1. fmhy/FMHY-SafeGuard on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases