Data Collection

This page explains where the data on this site comes from and how we turn it into fancy charts and tables.

Where the data comes from

All of our data is collected from public sources, including:

1. The public obsidian-releases repository. This is also used by the Obsidian app itself to populate the community plugins list.
2. Community plugin repositories on GitHub.
3. The GitHub API for metadata and release files.

It is important to note that we don’t run any code from plugins or themes. We rely entirely on static analysis of publicly available information.

How we extract and combine data

The data you see on this site is combined from the above mentioned sources. Through 2026-06-30, plugin download counts come from the Git history of the obsidian-releases repository. Starting on 2026-07-01, they come from GitHub release statistics collected for each plugin’s manifest.json asset. The change is a hard source switch: data from the two sources is not mixed within either period. The repository history also lets us see when plugins were added to the community plugin list, removed, or updated.

But not all data is directly available. For example, since there is no manifest field for the license of a plugin. Because of this we also analyze the plugin repositories and release files of currently listed plugins to derive additional data points. The more interesting of these data points are explained below.

License

Since there is no standard way for an Obsidian plugin to specify its license besides a license file, we scan the repository for license files and try to match them to known licenses. This is done by comparing the text of the license file to a database of known licenses. If we find a match, we assign that license to the plugin. If not, we mark it as either Unrecognized or Not Found depending on whether we found a license file at all.

Dependency usage

Most plugins use JavaScript or TypeScript, and they often have dependencies. We look at the package.json file in the plugin repository to see which dependencies are listed. This gives us insight into which libraries and frameworks are popular in the Obsidian plugin ecosystem. From this we can also derive the usage of certain categories of dependencies, such as UI frameworks, code bundlers, package managers, and more.

BRAT usage

BRAT (Beta Reviewers Auto-update Tester) is a popular tool for installing plugins straight from GitHub repositories, circumventing the official Obsidian community plugins list. It can also be used by plugin authors to distribute beta or preview versions of their plugins. One way to set this up is to include a manifest-beta.json file in the repository. We check for the presence of such a file to estimate how many plugins are using BRAT for distribution.

Glass Lint findings

For each available release main.js, we run the Glass Lint JavaScript and Obsidian catalogs in one analysis pass. The site uses these findings directly to populate the main.js findings table and charts.Additionally, the site introduces a new concept called disclosures. They map granular rule findings to a more general disclosure category to aid in interpreting Glass Lint’s findings. Note that Glass Lint is a static analysis tool and does not execute plugin code. It is possible for a plugin to have findings that are not actually reachable in practice. Similarly, it is possible for Glass Lint to miss findings in obfuscated or heavily minified code.

ECMAScript version

For each analyzed release, Glass Lint also reports the minimum ECMAScript edition required by the standard syntax in main.js, such as ES2017 for async functions and await. This is a syntax only heuristic and might be inaccurate.

Minification

We retain a separate heuristic minification detector for each available release main.js. It estimates a score from source formatting, punctuation, comments, and identifier lengths; the score and a probable-minification flag are reported separately from Glass Lint findings.