Paperlib: a metadata-first reference manager for conference-heavy fields

The conference-paper metadata gap Paperlib targets

The README opens with the author's own situation: a computer science PhD student whose community publishes mainly at conferences. Conference papers frequently have no DOI and no ISBN, so the metadata that DOI-based tools rely on simply is not there. The README names NeurIPS and ICLR as examples. The stated workflow problem is repetitive manual lookup: when citing a publication, the author had to search Google Scholar or DBLP again and again for the same information.

Paperlib's answer is to make metadata scraping the core function rather than a side feature. The README is blunt about the competition here, arguing that no software, commercial included, does metadata scraping well. That claim is a positioning statement, not a measured result, and the README offers no comparison data behind it. Treat it as the design premise, not as evidence.

The audience follows from that premise. If you work in a field where the journal article with a clean DOI is the norm, the problem Paperlib solves is mostly already solved for you. If your bibliography is full of workshop papers, preprints and conference proceedings, the value proposition is more direct.

How Paperlib is put together: Electron, Vue and a separate API package

The repository layout shows an Electron application. The top level contains electron.vite.config.ts, electron-builder.json5, a build_configs directory with per-platform builder configs, and an app directory split into main, service, extension and renderer TypeScript projects. The package.json scripts confirm the split: typecheck runs separately over app, main, service, extension and renderer, and the renderer check uses vue-tsc, which points to Vue for the interface layer.

There is also a paperlib-api directory at the top level, published alongside the app. That is the surface extension authors build against. The README points extension developers to a separate documentation site rather than describing the API inline, so the repository alone does not tell you what the extension contract looks like.

Builds are per platform and per architecture. The scripts include build-mac-arm, build-mac-x86, build-win and build-linux, each running vue-tsc, a vite build, then electron-builder with a matching config file from build_configs. There are also dev variants such as build-mac-arm-dev and build-win-dev. The practical consequence is that Paperlib is a desktop application, not a web service you host, and the repository carries real per-platform packaging work rather than a single universal build.

Installing Paperlib and importing your first paper

The README does not give command-line install steps for end users. It points to the download page at paperlib.app, and the download page is where the platform installers live. The README's own instructions are about getting past the operating system's gatekeeper, not about running a package manager.

On Windows, the README warns that a warning appears during installation and explains why: there is no code signing because it is expensive. It instructs you to click More info and then Run anyway in the Windows protected your PC window, and it asks you to verify that you downloaded over HTTPS from the official webpage or GitHub. On macOS, the README says you may need to open preference, then Security & Privacy, then run anyway. Linux users are sent to a separate download-linux page.

If you want to build from source instead, the repository exposes the development and packaging scripts. The dev script starts the Electron app with hot reload:

pnpm install
pnpm run dev

The package.json defines dev as electron-vite dev -w, so the -w flag is already baked into the script. Type checking is split by target, and you can run the whole set at once:

pnpm run typecheck

That command chains the app, main, service, extension and renderer checks. A production build for one platform looks like this:

pnpm run build-linux

Each of those build scripts runs vue-tsc, then vite build, then electron-builder against the matching config in build_configs. Once the app is running, the first real task is importing a paper and letting the scrapers fill in the record. The README describes the intended loop as import, scrape metadata as accurately as possible, organise the library, then export when writing. What the README does not document is a rollback path if a scrape writes bad metadata into an entry, or an undo for a bulk import. The getting-started documentation linked from the README is where that would have to live.

Where Paperlib gets in the way

The absence of code signing is the most concrete limitation, and it is stated plainly in the README rather than buried. On Windows you are asked to override a SmartScreen warning; on macOS you may have to change a security setting. On managed machines, or anywhere institutional policy blocks unsigned applications, that alone can rule Paperlib out. The README's mitigation is procedural: download only over HTTPS from the official page or GitHub. That is reasonable advice and also a burden shifted onto the user.

Scraper accuracy is the second risk, and it is the one Paperlib's own pitch creates. Scraping is best-effort by nature: a venue changes its site layout, a scraper returns a partial record, and nothing in the README describes validation or a confidence signal attached to scraped fields. The README does say you can write your own scrapers, which is the escape hatch, but that means the quality of your library partly depends on work you may not want to do.

The README also carries a notice that the author is looking for someone to work with on development. Combined with a release history that shows release-electron-3.1.12 on 2025-09-28 and release-electron-3.1.10 on 2024-12-22, the picture is a project with bursts of activity rather than a steady cadence. The last push to the repository was on 2026-04-01. That is not abandonment, but it is not a project you should assume will ship a fix the week you need it.

Paperlib against Zotero: different bets on metadata

The README raises Zotero and Mendeley by name and answers with one argument: metadata scraping is the core function of a paper manager, and nobody does it well. That is the whole comparison the project offers, and it is a claim about capability rather than a feature-by-feature breakdown.

The real difference in approach is where the metadata comes from. Zotero's model leans on identifiers and on connectors that capture records from publisher pages and library catalogues, which works when a DOI or an equivalent identifier exists. Paperlib's model leans on scrapers that go after the record directly, which is what you need when the identifier does not exist. For a NeurIPS paper with no DOI, that distinction is the entire argument.

The trade runs the other way too. Zotero has a long-established extension ecosystem and synchronisation across a large user base; Paperlib's README lists its own extension capabilities, including citation counts, LLM summarisation, LLM tagging, semantic search and chatting with papers, but those are Paperlib extensions, not a claim of parity. Paperlib's own sync is described in the README as cloud sync across macOS, Linux and Windows. If your group collaborates inside a shared Zotero library, Paperlib is not a drop-in replacement for that workflow, and the README does not describe group libraries at all.

Licence, releases and what upgrades cost you

Paperlib is licensed GPL-3.0, stated in the README and in the LICENSE file at the repository root, and the package.json carries the same identifier. If you only run the application, the licence is not something you interact with. If you write and distribute an extension, or fork the code, the copyleft terms apply to what you distribute, and the extension documentation is the place to check how that is handled. This is a description of the licence, not legal advice; if you plan to ship something commercial on top of Paperlib, get your own reading of GPL-3.0.

The upgrade story is visible in the repository. CHANGELOG_EN.md and CHANGELOG_CN.md sit at the top level, release-notes.md sits beside them, and the GitHub releases are tagged with a release-electron prefix, for example release-electron-3.1.12. The package.json version field reads 3.1.6, which does not match the newest release tag, so the version in the default branch is not a reliable indicator of what end users are running. If you need to know what changed between two builds, the changelog files and the release notes are the sources to read.

The maintenance cost is mostly on the scraper side. Paperlib's value depends on scrapers continuing to match live venue sites, and that is maintenance you either wait for upstream to do or take on yourself through the extension path. Budget for periodic re-checking of imported records after upgrades, because nothing in the README promises that a scraper fix will retroactively correct entries already in your library.

Editorial conclusion

Adopt Paperlib if your reading list is dominated by conference papers from venues such as NeurIPS, ICLR or ICML, where DOI-based lookup fails and you are willing to check scraped records by hand. Skip it if your library is book- and journal-centric, if your institution requires a signed installer, or if you depend on a mature plugin ecosystem and shared group libraries. Before committing, install it on one machine, import twenty real entries from your own field, and confirm that the bundled scrapers return correct titles, authors and venues for those venues. Then check the release-notes.md and CHANGELOG_EN.md files in the repository to see how often scraper fixes land before you move a full library across.

Frequently asked questions

Official sources

1. Future-Scholars/paperlib on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases