Omnisearch for Obsidian: a MiniSearch index wrapped around your vault
A search engine that "just works" for Obsidian. Supports OCR and PDF indexing.
At a glance
- What is it?
- A GPL-3 Obsidian plugin that indexes notes, PDFs, images and Office files and ranks them with MiniSearch. It is fast and keyboard-first, and it leaves two questions open: who really does the extraction, and what exactly is the scoring algorithm.
- Who is it for?
- Omnisearch is the right pick for a vault you search by name and keyword and want answered immediately, and the wrong pick if you need semantic retrieval or want to control how a scanned document gets read. Install the stable release from the community plugin list, add obsidian-text-extractor if PDFs or Office files matter, and check the ranking claim against Obsidian's own search on your own notes before you accept it.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Installing from the community plugin list, and the BRAT channel beside it
The plugin ships through Obsidian's own community plugin list, which is the low risk path: search for Omnisearch in the plugin browser, install, and Obsidian handles the download. There is no npm step and no build for end users. The repository is a TypeScript project built with esbuild and Svelte 5, and package.json names the file Obsidian actually loads.
"main": "dist/main.js",For anyone working from a clone, the scripts in package.json are the whole story. `dev` runs esbuild in watch mode, `build` type checks with tsc before producing a production bundle, and `test` is a single vitest run. The project pins its package manager, so pnpm is the expected tool rather than npm.
git clone https://github.com/scambier/obsidian-omnisearch.git
cd obsidian-omnisearch
pnpm install
pnpm run buildBetas are a separate channel. The README points at BRAT for pre-release installs and warns in plain language that those versions can be buggy and break things, and the repository backs that up: the tree carries both manifest.json and manifest-beta.json, and version-bump.mjs exists to keep them in step. Release 1.31.0-beta.1 shipped on 2026-08-25 and the final 1.31.0 followed on 2026-09-05 with a word for word identical changelog, which tells you the beta channel is the release train rather than a parallel line of work.
What MiniSearch 7.1.0 contributes, and what the plugin adds around it
Omnisearch does not implement ranking itself. package.json lists minisearch 7.1.0 as a direct dependency, and the README names the library and credits it. That matters for expectations: the plugin is a vault adapter, an indexing pipeline and an interface around a search engine somebody else maintains, and its behaviour changes when MiniSearch changes.
Three other runtime dependencies explain most of what it does. dexie 4.4.2 is the persistence layer, so the index survives restarts and can be rebuilt rather than recomputed on launch. search-query-parser 1.6.0 handles the query string, which is where quoted phrases and exclusions come from. es-toolkit 1.50.0 covers the string and object work, pure-md5 provides hashing, and markdown-link-extractor pulls outbound links out of note text so you can search by link target.
The library choice has a visible consequence. MiniSearch keeps the index in memory, so the structure lives inside Obsidian's renderer process and dexie is what holds a copy on disk. A vault with a lot of notes means a larger in-memory index, which is the price of answers with no query round trip.
The README states the goal in one line: locate files instantly, a Quick Switcher on steroids. That framing is honest about the scope. This is a lexical search plugin and does not pretend to be a semantic one.
Scoring, filenames and headings, and the gap between the claim and the config
The relevance claim is specific. The README says the score of a document against a query depends on how many times the query terms appear in the document, its filename and its headings, and it links that description to a comment on a MiniSearch issue rather than to any page in this repository. Read carefully, the README is asserting BM25 while sourcing the assertion to a third-party discussion, and the repository contains nothing that pins the scoring configuration: no scoring option in package.json, no settings file in the tree. Both facts are in front of you. The README says BM25 ranks your results. The repo shows a pinned MiniSearch release and no exposed scoring choice.
There is a way to settle it for your own vault rather than picking a winner on paper. Type the same rare term into Omnisearch and into Obsidian's built-in search across a handful of notes where you already know the ranking you would want, then compare where a title match lands against a body match. Run it right after a fresh index build so both sides work from the same text. If the order matches what the README describes, the claim holds for the version you installed. If it does not, the linked comment is describing MiniSearch behaviour rather than something this plugin configures.
The parts you can verify without that experiment are the weighting inputs. Filename and headings are treated as their own signals, so a note titled with your search term outranks a note that merely mentions it several times. Quoted queries are supported alongside exclusions, and the release notes for 1.31.0 record a fix to case-sensitive excerpt anchoring for quoted queries, which is the kind of detail that only matters if you search for exact phrases often.
Who extracts the PDFs, and who does OCR
The repository description for this project reads, in part, that it supports OCR and PDF indexing. The README says something narrower: images, documents and PDF indexing are available through a separate plugin, obsidian-text-extractor. Both statements sit in front of you at once and they are not saying the same thing.
The first is the short blurb GitHub shows in the repository header. The second is the plugin's own documentation, which assigns the work to a companion project. OCR is the sharpest edge of the disagreement, because the word appears in the repository description and nowhere in the README. Nothing inside this repository tells you whether the text of a scanned page arrives through the companion plugin, through some other path, or not at all.
The practical consequence is about what you install and where you look when a document does not show up. If your vault is mostly markdown, Omnisearch indexes that markdown on its own and the question is academic. If you have PDFs or Office files, you depend on a plugin maintained by the same author, and an extraction bug surfaces as Omnisearch failing to return a document you know contains the term. That is the first place to look, and it saves you from suspecting the ranking.
Chinese is the other documented boundary, and the README is unusually direct about it. Support depends on the third-party cm-chs-patch plugin, and you may need to clear the search cache for a new Chinese index to take effect. Typo resistance is listed as a feature without that caveat attached, so read the two claims together rather than separately.
The local HTTP server and the projects that depend on it
An opt-in local HTTP server lets something outside Obsidian query the index, and the README lists this as a feature rather than burying it. That capability is what makes the downstream projects possible. Omnisearch Companion is a browser extension that searches from Firefox or Chrome, Userscripts injects results into a web search engine, obsidian-mcp-server auto-detects Omnisearch and exposes it to AI agents as a BM25-ranked search mode, and Silversearch is a fork of Omnisearch for Silverbullet. Notebook Navigator and Actions for Obsidian appear in the same list.
That list is also the best available evidence about what the index is good for, since each entry is somebody else's answer to the same question. A browser companion is for a reader who wants vault search without switching to the app. An MCP server is for a reader who wants retrieval with term-based ranking rather than a hosted embedding service.
The keyboard-first design is the other thing to know before installing. Vim navigation keys, direct insertion of a wiki link from the result list, and the ability to flip between vault-wide and in-file search are all in the feature list. That last one is what makes scanning many results inside a single note practical rather than tedious.
Two documentation locations, one release shipped for a rating
The published documentation lives at the obsidian.md site, and the repository keeps its own copy in a Doc Omnisearch directory at the top level of the tree. Two locations for one set of docs is a normal Obsidian plugin arrangement, and it is also where to look when behaviour does not match what you read, since the published site can lag the branch.
Activity here is close and recent. The last push was on 2026-09-19, package.json declares version 1.31.0, and 1.31.0 shipped on 2026-09-05 with fixes for race conditions during adding and deleting files, Cmd+Click to open a result in a new tab on macOS, and a performance change that stops retaining normalized document content. That last one matters for a large vault, since holding normalized text in memory is exactly the cost an in-memory engine imposes.
One release deserves an eyebrow raised. Version 1.30.1, published 2026-07-29, describes itself as a technical release to appease Obsidian's automatic rating. Whatever that rating logic is, a version shipped for that reason shows that plugin versions are also a distribution concern, not only a code one, so the changelog is worth reading before jumping a minor version.
The licence is GPL-3, which is the constraint to keep in view if you want to reuse the code rather than install the plugin. Omnisearch is also unrelated to the paid omnisearch.ai product, and the README says so, which matters because the name collision makes search results for this plugin genuinely confusing.
Editorial conclusion
Omnisearch is the right pick for a vault you search by name and keyword and want answered immediately, and the wrong pick if you need semantic retrieval or want to control how a scanned document gets read. Install the stable release from the community plugin list, add obsidian-text-extractor if PDFs or Office files matter, and check the ranking claim against Obsidian's own search on your own notes before you accept it. The engine is a pinned MiniSearch 7.1.0 with no exposed scoring switch, Chinese support depends on a third-party patch plugin, and the documentation is split between the published site and the Doc Omnisearch directory in the repository, which is where to look when the two disagree.
Frequently asked questions
How do you use Omni Search in Obsidian?
Install it from the official community plugin list, then open it with the Quick Switcher style workflow the README describes, or with the plugin's own keyboard shortcut. Search across the whole vault or flip into in-file search, use quotes for an exact phrase and a minus sign to exclude a term, and press enter or insert a wiki link straight from the result list.
Does Omnisearch index PDFs and images itself?
The README says that images, Office documents and PDF indexing come through a separate plugin, obsidian-text-extractor, which the same author maintains. Markdown notes are indexed by Omnisearch on its own. OCR is named in the repository description but not explained anywhere in the README, so treat that one as unsettled.
Why does Chinese search not work out of the box in Omnisearch?
Chinese support depends on a third-party plugin called cm-chs-patch, which Omnisearch points at in its README. After installing it you may need to clear the search cache so the new Chinese index takes effect.
How does Omnisearch decide which result comes first?
The README says relevance depends on how often the query terms appear in the document, its filename and its headings, and describes that as BM25 provided by MiniSearch. package.json pins minisearch 7.1.0 and exposes no scoring option, so the algorithm is chosen by the library version rather than by a setting in the plugin.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/scambier-obsidian-omnisearch)