webappanalyzer: the Wappalyzer fingerprint catalogue kept open

The Wappalyzer catalogue after the original went private

webappanalyzer exists because of a discontinuity in the Wappalyzer project. The README states that this project is a continuation of the iconic Wappalyzer, which went private in August 2023, and that Enthec is committed not to set this repository private at any point, since that would be out of the scope of the company's business. The stated interest is keeping it growing so it stays useful to the community.

What that means in practice is stated just as plainly: there are no changes to be expected in the library, and it will be updated with the same JSON structure currently in use, so the user experience is not modified. This is a data continuation, not a rewrite. That constraint is the single most important fact for anyone evaluating the project, because it means the fingerprints, the field names and the detection semantics of the original are what you get.

The topic tags name the use case precisely: cms-detector, devtools, framework-detector, library-detector, webapp. The subject is technology fingerprinting, the practice of looking at a web page and working out what it is built with.

The repository layout backs this up. There is a `schema.json` at the root, a `src/` directory holding the technology definitions, a `scripts/` directory, a `.github/` directory with a validation workflow whose badge sits at the top of the README, and a `CONTRIBUTING.md`. There is no application code, no server and no crawler in the listing. The artefact is the catalogue.

A fingerprint is a JSON object full of regular expressions

The detection mechanism is described as a long list of regular expressions used to identify technologies on web pages. Wappalyzer inspects HTML code, JavaScript variables, response headers and more, and the patterns live in `src/technologies/`.

Each technology is one entry, and the example in the documentation shows the shape. The entry is keyed by the technology name, and it starts with a description and a list of category ids:

{
  "Example": {
    "description": "A short description of the technology.",
    "cats": [
      1
    ],
    "cookies": {
      "cookie_name": "Example"
    },
    "dom": {
      "#example-id": {
        "exists": "",
        "attributes": {
          "class": "example-class"

The same entry then carries the identity and metadata fields, which are mostly plain strings rather than patterns:

    "icon": "Example.svg",
    "cpe": "cpe:2.3:a:example:example:*:*:*:*:*:*:*:*",
    "js": {
      "Example.method": ""
    },
    "excludes": [
      "Example"
    ],
    "headers": {
      "X-Powered-By": "Example"
    },

and the entry closes with the links a consumer needs:

    "website": "https://example.com",
    "certIssuer": "Example",
  }
}

Two fields are required by the documentation: `cats`, the category ids, and `website`, the URL of the application's site. Everything else is optional, which is what makes the format workable for contributors. A technology that only sets a response header needs three lines; one that needs DOM structure, DNS records and script analysis needs a page.

The `cpe` field is worth a note, since it ties an entry to the CPE naming scheme rather than to a bespoke identifier, and `pricing` gives a cost indicator with values such as `low` and `freemium`.

The detection surface spans a dozen kinds of evidence

The optional properties are grouped by the kind of evidence they look at, and reading that list is the quickest way to understand what this project can and cannot see.

The base fields cover identity: `description`, `icon`, `cpe`, and the two booleans `saas` and `oss` for software as a service and open source software, plus `pricing` as a cost indicator.

The pattern fields cover observation. `cookies` matches cookie names and values. `dom` uses query selectors to check for an element, and can assert on its existence, its attributes, its properties and its text. `dns` matches DNS records such as MX entries. `js` matches JavaScript properties. `headers` matches HTTP response headers. `text`, `css` and `scripts` match against page source patterns. `robots` matches robots.txt content. `meta` matches meta tags such as a generator declaration. `url` and `xhr` match URL patterns. `probe` checks for the existence of a path, which is how a technology is confirmed by requesting something it would serve.

Then there is the logic layer. `implies` says the presence of one application can imply another, `requires` is similar but the detection only runs if the required technology has already been identified, `requiresCategory` does the same with a category id, and `excludes` removes a technology when another is present.

The distinction between `implies` and `requires` is the interesting part, because it changes what a consumer can do. An `implies` relationship is a conclusion the detector draws. A `requires` relationship is a precondition, which means the pattern is not even evaluated until the requirement is satisfied. A fingerprint that only holds under a condition, such as a script URL pattern that only exists on a particular framework's build, belongs in `requires` rather than in a bare pattern.

Adding a technology means writing JSON against a schema

The contribution model is data-first. The JSON schema lives at `schema.json` in the repository root and the documentation points to it directly, so the contract for a valid entry is machine readable rather than a prose description.

The `.github/` directory holds a workflow called `validate.yml`, and its status badge is the first thing in the README, which suggests the validation runs on every change. The `scripts/` directory at the root is the other half of that loop, since a catalogue this size needs a script to check consistency across entries as well as a schema to check the shape of each one.

`CONTRIBUTING.md` is present at the root, and the repository has both `.gitattributes` and a `.gitignore`.

For a consumer, this setup has a practical consequence. The JSON structure is a public interface with a schema and a validator behind it, so a consumer can pin a commit, diff two versions of the catalogue, and know that every entry will parse. The downside is equally clear: because the project states that no changes to the library are expected and that updates keep the same JSON structure, consumers get a stable format and a slowly growing data set, not new capabilities.

There are no GitHub releases for the project, so a consumer who wants a stable copy has to pin a commit rather than a version, and there is no published changelog to diff against. The repository is not archived and the last push was on 2026-10-19, so the data set is being maintained.

Static fingerprints against behavioural detection

The real alternative to this approach is not another fingerprint database, it is a different way of answering the same question. Instead of asking what a page looks like, a behavioural detector observes what the page does: which hosts it calls, which scripts it loads, which API shapes it uses, how the application responds to a login attempt, and which frameworks the stack traces reveal.

The difference in approach shows up in what each one can conclude. Fingerprint matching is cheap, stateless and works against a single fetched page, which is why a catalogue of regular expressions is the practical way to fingerprint thousands of sites quickly. Its weakness is that it only recognises what has been written down, and a site that hides its fingerprints or uses a custom build of a known framework will not match, while a site that mentions a framework's name in a comment can match spuriously.

Behavioural observation needs the page to run, which costs a browser and a sandbox, and it identifies the stack from artefacts the technology leaves behind rather than from declarations it makes. Its weakness is that it needs a live session and produces answers that are harder to store in a versioned catalogue, because they describe a run rather than a signature.

The two are complementary in practice. A catalogue of static patterns is a good index and a good filter, and it is the kind of artefact that can be reviewed by a community, since a human can read a regular expression and judge whether it is reasonable. The trade is that its coverage is exactly as good as its contributors, and its precision depends on patterns being written narrowly enough to avoid false positives.

One more limit deserves stating: `requires` and `excludes` exist because the pattern language alone is ambiguous, and those relationships encode the judgement of whoever wrote the entry. They are also where a catalogue accumulates its opinions, and opinions are what age badly.

Editorial conclusion

webappanalyzer suits anyone who wants to detect known technologies on a page from a self-hosted, auditable fingerprint set, and who is prepared to contribute patterns for technologies that are missing. It does not suit anyone looking for a ready-made scanner with its own fetching, rendering and reporting, since this repository supplies the detection data and the schema rather than a crawler, and it does not detect anything that is not in the catalogue. Before depending on it, check the JSON structure against schema.json, plan for the fact that the only releases are not tagged, and remember that the project states the library will keep the same JSON structure with no expected changes.

Frequently asked questions

Official sources

1. enthec/webappanalyzer on GitHub
2. Issues
3. License: GPL-3.0
4. README