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.

ECMAScript version

The ES (ECMAScript) version that a plugin targets determines which JavaScript features it can use. Generally it is preferable to use a newer ECMAScript version, as it allows for more modern and efficient code. However, it also means that the plugin may not work in older versions of Obsidian.

We estimate the ECMAScript version of a plugin by looking at the main.js file in the release assets. This is the file that is actually distributed to users, so it gives us a good indication of what features are being used in practice. We parse and scan the file for modern JavaScript features and use that to estimate the minimum ECMAScript version required to run the plugin. It is important to note that this is an estimate and may not be 100% accurate.

Minification and embedded content

Code bundlers that turn the potentially many source code files of a plugin into a single main.js file often also minify the code. This makes the code more difficult to read, but results in smaller file sizes and faster load times. So it is generally advisable to minify the code for production releases. We check for minification by looking for certain patterns in the main.js file, such as very short variable names and a lack of whitespace. We also calculate a minification score based on the ratio of whitespace to non-whitespace characters. However, this is not an exact science and there may be false positives or false negatives.

Worker and WebAssembly usage

Web Workers allow JavaScript code to run outside the main UI thread. WebAssembly (Wasm) is a compact binary instruction format that allows code compiled from languages such as Rust or C++ to run in Obsidian’s JavaScript environment. We scan main.js for references to Worker and WebAssembly APIs. These references indicate that a plugin may use the APIs, but static analysis cannot confirm which code paths run. Positive matches are included in the API findings and disclosures.

API findings

We parse each available release main.js and look for known Obsidian, browser, Node.js, and Electron API patterns. The classifier uses import provenance, member access, call arguments, string literals, and several flow-sensitive checks to reduce false positives. It does not execute plugin code, and minified or dynamically generated code can still produce missed or incorrect findings.

The public data includes warning-level matches and high-confidence informational matches. This also includes source map comments, large embedded base64 blobs, Worker usage, and WebAssembly usage. Lower-confidence informational matches are omitted to keep the displayed results conservative.