How the index reads plugins
Each day, a build reads every listed plugin's GitHub repository and releases. A plugin page shows the facts that a build found for one release, the release the index read. A maintainer reads the paid service fact by hand, and the build reads the others. This page says where the main facts come from and what they do not show. It also says how to install a plugin, and it ends with the license terms.
Declared range
A plugin's manifest declares the Zotero versions that it supports, in its strict_min_version and strict_max_version fields. The index shows that range for the release it read, after its overrides.
- The range covers every release of that Zotero version, up to its newest release.
- The range covers part of it.
- The range covers none of it.
The index counts Zotero N as the versions from N.0 to the newest release of N. So a maximum such as 10.0.* covers all of Zotero 10 while 10.0 is its newest release line, and part of it once Zotero 10.1 is out. A range that ends before N.0 or starts after the newest release covers none of it, so a minimum such as 8.999, which authors write to mean Zotero 9 and newer, covers none of Zotero 8. Each day the build reads the current Zotero release from zotero.org, and the index keeps the last release of each earlier Zotero version. For a Zotero version with no known release, the index counts N.0 to N.9, because authors often write a maximum such as 10.99.99 to mean every Zotero 10 release. A plugin that declares no range shows no mark. The range is what the author declares, not a test result.
This build used these newest releases:
- Zotero 7: 7.0.32
- Zotero 8: 8.0.5
- Zotero 9: 9.0.6
- Zotero 10: 10.0.7
Start test
The build installs the plugin version that the index read in a new Zotero profile on Linux. It does this for each tested Zotero release that the manifest's range covers. It waits 3 seconds after the install, and then it reads one of four results.
The build does not start every plugin each day. It starts a plugin in a tested release when the plugin file differs from the one last tested, when that release has no earlier result, or when the last result was not a start. It also starts each plugin again on one day of each week, and every plugin on a day when it cannot read the last published data. On the other days it keeps the last start result, so a result is most often up to a week old. A plugin with older data gets no start test until a build reads it again. If the build on the weekly day deploys nothing, the result stays another week.
- Started: Zotero lists the plugin as active, and the plugin logged no startup error.
- Failed at startup: the plugin's startup threw an error, or an async startup rejected, in those 3 seconds.
- Did not install: Zotero does not list the plugin, or lists it as inactive.
- Gave no answer in time: no result came within 90 seconds.
A start is not a report that the plugin works. The test does not use the plugin, and an error after the 3 seconds still counts as a start. The plugin's own code runs during its test, so a plugin can change its own result.
Older data
Sometimes the build cannot read a plugin because of a problem with the build or a host, such as its time limit, a read that takes too long, or a server error. If the published data holds facts about the plugin that a build read at most 7 days before, the site keeps them. The plugin's row has an "Older data" badge, and its page names the day of that read and the problem. A plugin that the build cannot read for another reason, such as a deleted repository, shows "Not read". The 7 days count back from each build, and a build can fail to update the site, so kept facts on the site can be older. A plugin with older data gets no start test, and it keeps the start results published with its facts.
User reports
Anyone with a GitHub account can report that a plugin version works or is broken on a Zotero version. The Works and Broken buttons on a plugin page open the report forms on GitHub. A bot checks each report and closes it.
The index counts a report only when the bot closed it as completed and the report names the plugin version that the index read. A report with the label not-counted does not count. Of one GitHub account's reports on one plugin and Zotero major, only the newest counts. When the index reads a new release of a plugin, its counts start over. The counts say what reporters found, not what the index tested.
Descriptions
A plugin's description comes from its manifest or from the About text of its GitHub repository. For the manifest name and description that name a locale message, the index reads the plugin's English locale file first, if it has one.
A description override that applies to the version the index read comes first. Without one, the site takes the Latin-script part of each description of which half or more is Chinese, Japanese, or Korean. It cuts the text at each / with a space on each side and after each 。. It keeps the pieces whose letters are all Latin and that hold at least three words, and it joins them with one space. If that part exists and does not only repeat the plugin's name, the site uses it in place of the whole text. A piece in another language that uses Latin letters, such as Portuguese, shows as it is.
The site then drops a description that is missing, blank, or only repeats the plugin's name. Last, if less than half of the manifest description is Chinese, Japanese, or Korean, the site shows it. If not, the site shows a GitHub description that it kept in two cases: the manifest description was dropped, or the GitHub description has less of that text. The Details card of a plugin page shows both descriptions, unless one is missing or blank.
Overrides
When an upstream fact is wrong and the author cannot or will not fix it, the index can correct it with an override. An override corrects one field: the name, the description, the homepage, strict_min_version, strict_max_version, or the languages list. It applies to one plugin version or to every version. A description override can also give English text for a plugin with no English description upstream. That covers a description that is not in English, that only repeats the name, or that is half or more Chinese, Japanese, or Korean. It can also replace an English description of fewer than six words.
A repository's owner can also ask for a name or description override, through the link in the plugin's Details, after trying an upstream edit first. The text is in English. A name has 2 to 40 characters, and a description has at least 6 words and at most 200 characters. A maintainer reads each request. The text stays through new releases until the owner asks to remove it.
The Overrides table in a plugin's Details lists each override beside the upstream value. Its Used column says "yes" for the override that applies to the plugin version that the index read. An override for that version wins over one for every version. The declared range uses the strict_min_version and strict_max_version overrides marked "yes". A description override lists both upstream texts, the manifest description and the GitHub description, when the plugin has them.
Categories
The index sorts plugins into categories of its own, so that you can find plugins of one kind. It assigns them from words in a plugin's name and descriptions, and it adds or removes some by hand. A plugin can have several categories. A plugin that fits no other category is under Other tools. A plugin that the latest build did not read, and that keeps no older data, has only the categories added by hand, so it often shows none. A category can be wrong or missing. Plugin authors do not choose them, but a requested name or description can change the words they read.
- AI assistants: chat with papers, AI summaries and explanations, and AI agents inside Zotero
- Translation and dictionaries: translated text and PDFs, bilingual reading, dictionaries, and vocabulary
- PDF reading: the PDF reader's view, focus aids, navigation, and text-to-speech
- Notes and annotations: notes, annotations, and mind maps
- Citations and writing: citations in Word and LaTeX, BibTeX, and citation styles
- Metadata and cleanup: item metadata, DOIs, titles, author names, and duplicates
- Attachments and full text: finding and downloading PDFs, renaming and moving files, snapshots, and OCR
- Journal rankings and citation counts: journal and conference rankings, impact factors, and citation counts
- Export and sync: Markdown files, Obsidian, Notion, reading apps and tablets, and backups
- Search and discovery: finding papers, preprints, related work, and citation graphs
- Library organization: tags, collections, item columns, feeds, and reading status
- Appearance: color themes, dark mode, and the look of Zotero's window
- Connections for AI tools: MCP servers and local endpoints that let outside AI tools reach your library
- Window, tabs, and shortcuts: how the main window behaves, tray icons, tabs, keyboard shortcuts, and small menu and toolbar changes
- Other tools: plugins that fit none of the categories above
Source code
A lock beside a plugin's name means that the index found no source code at the top level of its repository. Each day the build reads the top-level file and folder names of the repository's default branch, for each plugin that it could read. The index reads no code to decide this. These names do not count as source code, in any letter case: a name that starts with a dot; README, LICENSE, LICENCE, COPYING, NOTICE, CHANGELOG, or CHANGES, with or without one extension; a name that ends in .xpi, .md, .txt, .rdf,.png, .jpg, .jpeg, .gif, .svg, or .webp;update*.json; and docs, doc, images, image, img, assets, screenshots, dist, build, releases, update, and updates. Any other name does.
The plugin page shows the result as "Source code at the repository's top level". "Yes" does not mean an open-source license, and it does not mean that the XPI was built from that code. "Yes" can be wrong, because a name such asLICENSE-MIT counts. "No" can be wrong, because the index does not look inside folders. A plugin with the lock stays listed, because the index states this as a fact and does not judge plugins by it.
Paid service
A card icon beside a plugin's name means that the plugin's main use stops without paying its maker, or stops after a trial, whether the payment is for credits, a membership, an activation code, or a paid plan. A maintainer reads this by hand from the plugin's own text. The plugin page's Details card gives a note on what is paid for, a link to the source, and the date of the read.
A lasting free plan with a paid upgrade gets no mark. A plugin that also works with a third party's key gets no mark. A donation gets no mark. A plugin with no mark can still cost money, because the maintainer reads new plugins later and does not read every page about a plugin. A marked plugin stays listed, because the index states this as a fact and does not judge plugins by it. An author can open an issue to correct it.
Removing a plugin
A maintainer removes a plugin from the index for any of four reasons: its repository's owner asks, it is spam, its entry misleads people about what the plugin is or who makes it, or a report shows harm with evidence that a reader can check. A claim with no evidence removes nothing. To ask, use the form for removing a plugin or reporting harm, or the link on the plugin's page. The form opens a public GitHub issue, and a maintainer answers there.
A removed plugin stays off the index, and the bot does not propose it again. A list names its repository and, when a maintainer judges it unique, its plugin id, so a copy under a new name is covered only if it keeps a listed id. The index still cannot vet plugins, and it does not review their code.
Installing a plugin
To install a plugin, save its .xpi file to your computer. Then, in Zotero, go to Tools → Plugins and drag the file onto the Plugins window. In Firefox, right-click the download link and choose Save Link As.
A plugin has full access to your Zotero and your computer, so install only plugins from developers you trust.
A bot adds most new plugins on its own. If one of the bot's checks flags a plugin, the bot waits, and a maintainer decides whether to list it. A maintainer can also add a plugin by hand or keep one out. When deciding, a maintainer mainly checks whether the entry would mislead people about what the plugin is, who makes it, or who controls its updates. A maintainer can compare files to spot a copy, but does not review the code. The index does not review a plugin's code before listing it.
What the index does not do
The index is unofficial: it is not affiliated with or endorsed by Zotero. It cannot vet the plugins it lists, because one person maintains it and each plugin can change with any release. The start test is not a review of plugin code: it shows only whether a plugin starts. The index does not endorse plugins. It does not host plugin files: the download link on a plugin page goes to the author's own file, which the index does not copy.
License
The index's code is under the MIT License, except the third-party parts of the files that the README names. The icons on these pages come from Lucide, under the ISC License, and from Feather, under the MIT License. The facts that the index gathers, its categories, and text that a maintainer wrote are under CC0 1.0. All other text keeps its author's terms: plugin names and descriptions, GitHub About text, and text that an owner asked for. The README's License section gives the details.