← Obsidian Plugin Review Checker
Obsidian's developer guidelines name the required manifest.json fields, explain that
versions.json needs its own matching entry for the current version, and call out
innerHTML/outerHTML/insertAdjacentHTML as a cross-site-scripting
risk to avoid. What they do not do is read your specific manifest.json, your specific
versions.json, or your specific source files and tell you which one you actually got
wrong, in which file, on which line. That cross-check has always meant either a guess informed by the
docs, or a definite answer from a reviewer's comment on your pull request days later.
Obsidian's documentation is complete and authoritative about what the requirements
are. It is not a scanner: it cannot look at your project and tell you that your manifest.json
still carries the sample plugin's "id": "sample-plugin", because it has never seen your
files.
A reviewer's comment will eventually tell you, with certainty -- after you open a pull
request in obsidianmd/obsidian-releases, wait for it to be read, and get a comment naming
the exact field or line. For a versions.json entry that quietly fell out of sync with
manifest.json, that comment may be the first time anyone notices.
This checker runs the same field, placeholder, and API checks a reviewer would, against
your manifest, your versions.json, and your source, before you submit -- in the browser
(nothing uploaded) or as a Node CLI you can gate CI on.
| Question | Where to answer it |
|---|---|
| Which field, placeholder, or API call is the problem, and where? | This checker's scan -- file and line, free, nothing uploaded. |
| What are the required manifest fields and their names? | This checker lists them; both it and Obsidian's docs agree, since this tool's field list is checked against Obsidian's published guidelines. |
| Will the community plugin list actually approve my submission? | Neither. Only Obsidian's own review determines that -- this is evidence about your files as they stand today. |
| Is my plugin's source code uploaded anywhere? | No. The browser tool reads files with the File API; the CLI never makes a network call. |
It lists the required manifest.json fields, explains that versions.json needs its own matching entry for the current version, and names innerHTML/outerHTML/insertAdjacentHTML as a cross-site-scripting risk to avoid. What it doesn't do is read your specific manifest.json, your specific versions.json, or your specific source files and tell you which one you actually got wrong, in which file, on which line. That cross-check is what used to mean either guessing from the docs or finding out from a reviewer's comment.
A round trip on your pull request in obsidian-releases, at minimum -- open a submission, wait for a maintainer or bot to read it, get a comment naming the exact field or line, push a fix, and wait again. For a plugin id or author field still carrying the obsidian-sample-plugin template's default value, or a versions.json entry that quietly fell out of sync with manifest.json, that comment may be the first time anyone notices. Scanning before you open the pull request catches the same defect without spending a review round trip to find it.
You can, and for a small plugin it may be faster than downloading a tool. The risk is coverage: six required manifest fields, three template placeholder values, a versions.json cross-reference, and three DOM APIs to grep for across every .js/.ts/.jsx/.tsx file in the project -- easy to miss one on a plugin with more than a couple of source files. This tool runs the same checks against every file you point it at, in the browser or as a CI-gating CLI, so a placeholder or an unsafe assignment buried in a file you didn't think to check is not the one a reviewer finds first.
No, and it is not built to. This is pattern-matching against known manifest/versions.json field names and known risky API calls in the files you point it at -- a line-level heuristic, not data-flow or runtime analysis. It can miss an innerHTML assignment built from a genuinely safe value, or a guideline this tool does not check at all. A clean report means your current files agree with the specific patterns this tool checks; it is not a guarantee of approval, so verify against Obsidian's current plugin guidelines before you submit.