Anything (Docufinder): offline full-text search for Korean documents, including HWP

The gap Anything fills: HWP body text on a local disk

Windows search and most cross-platform indexers read file names, or parse a narrow set of formats. Korean offices run on HWP and HWPX, and those are the formats general-purpose tools skip. Anything targets exactly that gap. The README describes it as a search engine that finds documents by what is inside them rather than by file name, and the supported-format table lists .hwp and .hwpx first, parsed through an engine the project calls kordoc, with HWP5 and the older HWP3 files from 1996 to 2002 handled by automatic conversion. Beyond Hangul, the table covers .docx, .pptx, .xlsx and .xls (with sheet and row position tracked), .pdf, .txt and .md with EUC-KR and CP949 auto-detection, .eml with charset decoding, and images through OCR when the user enables it.

The intended user is someone with a folder of contracts, reports or meeting minutes who remembers a phrase but not the file name. The README's own examples are budget and leave-policy questions, which suggests an internal-document audience rather than a developer one. There is no server component: the README states the installer alone is enough for search, indexing and OCR, and that the default configuration downloads nothing at runtime. That claim matters for anyone whose files cannot leave the machine.

How indexing and search actually work

The stack is Rust for the backend and React inside a Tauri 2 shell, with SQLite FTS5 as the search index. The topics list also names ONNX, which lines up with the optional embedding model used for semantic search. Two search paths run in parallel. File name search reads from an in-memory cache and, per the README, works immediately, even before indexing finishes. Content search reads the FTS5 index and is fed by a watcher that picks up added, modified and deleted files and applies them incrementally, so there is no manual re-index step in normal use.

Parsing is where the project spends its complexity. HWP goes through a Node sidecar (node.exe running kordoc), which the README lists as a required child process even in the Lite build. Page numbers in results are reconstructed from the typesetting information that Hangul itself stores, which is why the README says page badges appear only for documents re-indexed after v3.8.1 and not for programmatically generated files that carry no such information. That is an honest limitation stated up front, and it tells you the page feature is a best-effort reconstruction rather than a stored offset.

Preview is a second rendering path. Text preview is the default; a layout view (key 1 for text, key 2 for original layout) renders .hwpx through kordoc SVG, .pdf as page images, and .hwp through something the README calls rhwp, described as native rendering without a Hangul installation. PDF OCR and LaTeX recognition are off by default and enabled in settings.

Installing it, and the WebView2 dependency that trips people up

Downloads come from the GitHub Releases page. For a personal Windows 10 (21H2 or later) or Windows 11 machine, the README points to a single file: Anything_<version>_x64-setup.exe, roughly 380 MB. Machines without the Microsoft Edge WebView2 runtime need MicrosoftEdgeWebView2RuntimeInstallerX64.exe (about 199 MB) installed first, ideally with administrator rights, before running the app setup. The README is explicit that WebView2 is what draws the interface, and that company PCs and LTSC builds often lack it.

For air-gapped or one-way transfer machines, the project deliberately abandoned a single combined installer (the old ...-ltsc-setup.exe, about 573 MB) because large files were arriving corrupted. The current instruction is to carry the two files separately and install WebView2 first. Stated requirements are 8 GB of RAM (16 GB recommended) and 1 GB of free disk.

Optional features download their own models the first time they are enabled: semantic search pulls an embedding model of about 106 MB, and LaTeX recognition and layout analysis each fetch a model once. If you want to block network attempts entirely, the README gives a system environment variable, DOCUFINDER_OFFLINE=1. Setting it disables layout analysis, which the README notes is online-only, while leaving OCR, search and indexing working. The Lite build is a separate installer, Anything.Lite_<version>_x64-setup.exe, around 280 MB and Windows only, built for internal networks where security agents such as AhnLab V3 or ZombieZERO quarantine or block the app. The README says the network code is removed at compile time, that no HTTP or TLS stack or external host strings remain in the binary, and that CI verifies this on each release. Lite drops semantic and hybrid search, OCR, AI question answering and summarisation, auto-update and automatic error reporting, and keeps full-text search, file name search, parsing and preview for the listed formats, live watching, incremental indexing, document comparison, tags, bookmarks, duplicate finding and export. Its settings and database are stored separately from the standard build.

The AI features are optional, and the README treats them that way

Question answering and summarisation call an external provider: Gemini, or any OpenAI-compatible server, which the README says can include vLLM, Ollama or LiteLLM running on-premises. An API key is required for both features, and the README states plainly that search works normally without one. Answers cite the source document and page, and there is an MD save button that writes the question, answer and referenced documents to a single Markdown file.

This is the right framing. The AI layer is additive, not load-bearing, and the offline guarantees in the README apply to the core product rather than to these features. Anyone evaluating Anything for a locked-down environment should read the Lite feature list carefully, because Lite removes the AI features entirely rather than routing them somewhere local.

A separate export path has nothing to do with AI: right-clicking a result and choosing Markdown save extracts the document body to a .md file, added in v3.8.2. The README notes the menu appears only for formats the parser reads (hwp, hwpx, docx, pptx, xlsx, xls, pdf, txt, md, eml) and that it works from file name search results too, without opening the preview. Password-protected documents must have their password entered in the preview first.

Where it is the wrong tool

The obvious constraint is platform. Windows and macOS only, with the Lite build Windows only and the README noting that Lite and macOS use manual updates rather than the in-app update notification. There is no Linux build in the material, and no server or headless mode described, so Anything cannot be dropped onto a shared index server or run in CI.

Size is the second constraint. A 380 MB installer plus a 199 MB runtime is a lot to move across a one-way link, and the README's own account of the abandoned 573 MB combined installer shows that transfer reliability is a real problem in that environment, not a theoretical one. The Lite build at 280 MB reduces but does not remove this.

The third constraint is subtler: Anything indexes a folder you register, and the watcher keeps that index current. That model suits a workstation with a stable document folder. It does not suit a corpus that lives on a network share with thousands of concurrent writers, and the README says nothing about how the watcher behaves under that load. Treat any such deployment as unverified.

Finally, the DRM fallback deserves scepticism before it deserves trust. The README describes a v3.8 Windows-only, off-by-default setting under settings, search tab, called roughly 'read files with installed MS Office', which opens documents through a licensed Word, Excel or PowerPoint when every other parser has failed, with the Office window hidden and macro auto-execution blocked. It is a last-resort path that depends on a licensed Office installation being present and permitted to read the file. On machines where that is not true, the fallback does nothing.

The alternative, and where the approaches diverge

The natural comparison is Everything, which the README itself invokes when describing file name search: type part of a name and get results instantly from an in-memory cache. The difference in approach is the index. Everything builds an index of file system metadata and never opens the files, which is why it is small, fast and indifferent to format. Anything parses document bodies, which means it must ship format parsers, a Node sidecar for HWP, optional OCR models and an embedding model, and pay for that with a multi-hundred-megabyte installer.

If your problem is finding a file whose name you half-remember, Everything is the better answer and Anything is overkill. If your problem is finding a phrase that exists only inside an HWP or a scanned PDF, Everything cannot help at all, and that is the case Anything was built for. The two tools are complements rather than substitutes, and the README's decision to replicate the file name search experience inside Anything suggests the author knows users will otherwise keep both open.

Licence and maintenance cost

The repository metadata reports the licence as NOASSERTION, while the README badge and the licence link both point to BSL 1.1. Business Source License 1.1 is source-available rather than open source in the OSI sense, and it typically carries terms about who may offer the software as a service and a change date after which the licence converts. The supplied material does not include the licence text, so the specific grant, the change date and the conversion licence cannot be confirmed here, and this is not legal advice. Anyone planning to redistribute Anything internally or bundle it into a product should read the LICENSE file in the repository rather than rely on the badge.

Maintenance signals are visible in the release history: v3.8.4, v3.8.3 and v3.8.2 shipped between mid-August and early September 2026, and the last push to the default branch matches the newest release. That cadence suggests active work, but it also means the on-disk index and the settings format move. The README already documents one such boundary: page badges only appear for documents re-indexed after v3.8.1. Upgrades therefore carry a re-index cost for anyone who wants the newer metadata, and the Lite build's separate settings and database mean a Lite user cannot carry a standard build's configuration across and expect the removed features to reappear.

Editorial conclusion

Adopt Anything if your corpus is Korean office documents, especially HWP or HWPX, and you need the body text searchable without sending files to a server. Do not adopt it if you need a headless indexer, a Linux build, or permissive licensing for redistribution. Before rolling it out, verify three things on your own machine: that WebView2 is present or installable, that your security agent does not quarantine the installer, and whether the BSL 1.1 terms cover how you intend to deploy it.

Official sources

1. chrisryugj/Docufinder on GitHub
2. Issues
3. README
4. Releases