Upgrade StorageAutoAttach - a plugin that matches downloaded PDFs, and Metadatas to Items In Your Library.
I've been running a PRISMA-style systematic review in Zotero and kept hitting the same wall: I had the items, I had the PDFs sitting in my downloads folder, and nothing would put the two together.
ZotFile and Attanger's Match Attachment both compare the filename to the item title. That doesn't work when the file is called 1-s2.0-S0140673623.pdf, or download (3).pdf, or when you've had to edit a title because Windows won't accept a colon, question mark or forward slash in a filename, which is most of my library.
So I wrote AutoAttach. It opens each PDF and matches on what's actually in the document: the DOI, an arXiv ID, embedded document metadata, and the first-page text.
Here it is in my own library, 171 PDFs scanned against 268 items, 146 matches:
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/swwqqklik8wuoypcd7pl.png
Nothing is written until you press Attach. Every proposed match shows its score and the evidence behind it; high-confidence rows come pre-ticked, and the header says plainly what it couldn't do: one scanned PDF with no text layer and four rows left unticked because a second item scored almost as well.
That last part is the bit I'd point at. A score on its own doesn't tell you whether to trust it: an 0.86 whose nearest rival scored 0.85 is a coin flip; an 0.86 whose nearest rival scored 0.36 isn't. So each row also shows how far clear it is of the runner-up, and a close contest is never pre-ticked however high the score. That case is common in a review corpus, where the same authors publish a baseline and an endline a year apart.
A few related commands in the same style
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/q9t4uz7xch9nwrqkuxdy.png
The three that use the network are labeled "Online" in the menu and name what they queried in the results header. Everything else is entirely local.
Find Missing DOIs searches Crossref, then OpenAlex for what Crossref doesn't have. It's built around refusing rather than guessing: a wrong DOI propagates into your deduplication, your retraction screening, and your final reference list, and nothing downstream will ever question it. So three signals are weighed asymmetrically: one that actively disagrees (wrong author, wrong year) rejects the candidate even on an identical title, while one that merely can't be checked only downgrades it. Only a near-identical title with author and year corroborated is pre-ticked, everything else is offered unticked with the returned title shown so you can read it first.
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/0m26owkze9n56elar9y7.png
A relevance score is never treated as evidence. Searching Crossref for "Coverage and determinants of modern contraceptive use in sub-Saharan Africa" returns, at score 49.6, a paper called "Predictors of modern contraceptive use among adolescent girls and young women in sub-Saharan Africa": same author, same year, same region, different paper. Scores rank candidates, they don't accept them.
A fair number of items in my corpus are grey literature, African Union strategies, national policy documents, NGO reports, which frequently have no DOI at all. "No DOI exists" is a normal outcome there rather than a failure, and it's reported as such instead of the closest-looking match being reached for.
Check for Retractions looks up every DOI against OpenAlex, fifty per request:
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/2x21hld4u6rfyraj2aoj.png
An item that couldn't be checked is never counted as sound. Items with no DOI, and DOIs OpenAlex has no record of, are listed alongside any retractions rather than quietly dropped, a screening pass that omits them reads as a clean bill of health when it isn't.
There's also renaming to your filename template, and a check for whether an abstract actually belongs to the PDF it's attached to (that one is reported, never repaired, either the abstract is wrong or the PDF is, and the plugin can't tell which).
Every run that changes something is journalled and can be undone per change, and writes a CSV listing every decision, including the items it couldn't match and why, which is the part you need when you come to write the methods section.
Please note that I am a third-party and unofficial. I'm the only maintainer.
Developed and tested against Zotero 9. The manifest allows 7.0 and up, but I have no Zotero 7 install to test on; if you're on 7, I'd genuinely like to hear whether it works.
Scanned PDFs with no text layer can't be matched on content; they fall back to filename similarity. Run OCR first. The dialog tells you how many files this affected.
It reads the first 3 pages of each PDF by default. Raise it in settings if your sources push the DOI onto page 2 or 3.
The initial implementation was generated with Claude, then debugged and hardened against a live library over a dozen releases.
Install
Download autoattach-1.0.1.xpi from the release below (right-click, Save link as, don't let the browser open it), then Tools > Plugins > gear icon > Install Plugin From File.
https://github.com/adolinjonathan-bot/zotero-toolkit/releases/tag/pdf-file-attacher-v1.0.1
Source and full documentation: https://github.com/adolinjonathan-bot/zotero-toolkit/tree/main/plugins/pdf-file-attacher
MIT licensed.
Feedback is welcome, particularly on Zotero 7 and on whether the confidence defaults (82% to auto-tick and 55% to offer) feel right on libraries that aren't shaped like mine.
ZotFile and Attanger's Match Attachment both compare the filename to the item title. That doesn't work when the file is called 1-s2.0-S0140673623.pdf, or download (3).pdf, or when you've had to edit a title because Windows won't accept a colon, question mark or forward slash in a filename, which is most of my library.
So I wrote AutoAttach. It opens each PDF and matches on what's actually in the document: the DOI, an arXiv ID, embedded document metadata, and the first-page text.
Here it is in my own library, 171 PDFs scanned against 268 items, 146 matches:
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/swwqqklik8wuoypcd7pl.png
Nothing is written until you press Attach. Every proposed match shows its score and the evidence behind it; high-confidence rows come pre-ticked, and the header says plainly what it couldn't do: one scanned PDF with no text layer and four rows left unticked because a second item scored almost as well.
That last part is the bit I'd point at. A score on its own doesn't tell you whether to trust it: an 0.86 whose nearest rival scored 0.85 is a coin flip; an 0.86 whose nearest rival scored 0.36 isn't. So each row also shows how far clear it is of the runner-up, and a close contest is never pre-ticked however high the score. That case is common in a review corpus, where the same authors publish a baseline and an endline a year apart.
A few related commands in the same style
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/q9t4uz7xch9nwrqkuxdy.png
The three that use the network are labeled "Online" in the menu and name what they queried in the results header. Everything else is entirely local.
Find Missing DOIs searches Crossref, then OpenAlex for what Crossref doesn't have. It's built around refusing rather than guessing: a wrong DOI propagates into your deduplication, your retraction screening, and your final reference list, and nothing downstream will ever question it. So three signals are weighed asymmetrically: one that actively disagrees (wrong author, wrong year) rejects the candidate even on an identical title, while one that merely can't be checked only downgrades it. Only a near-identical title with author and year corroborated is pre-ticked, everything else is offered unticked with the returned title shown so you can read it first.
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/0m26owkze9n56elar9y7.png
A relevance score is never treated as evidence. Searching Crossref for "Coverage and determinants of modern contraceptive use in sub-Saharan Africa" returns, at score 49.6, a paper called "Predictors of modern contraceptive use among adolescent girls and young women in sub-Saharan Africa": same author, same year, same region, different paper. Scores rank candidates, they don't accept them.
A fair number of items in my corpus are grey literature, African Union strategies, national policy documents, NGO reports, which frequently have no DOI at all. "No DOI exists" is a normal outcome there rather than a failure, and it's reported as such instead of the closest-looking match being reached for.
Check for Retractions looks up every DOI against OpenAlex, fifty per request:
https://s3.amazonaws.com/zotero.org/images/forums/u19347220/2x21hld4u6rfyraj2aoj.png
An item that couldn't be checked is never counted as sound. Items with no DOI, and DOIs OpenAlex has no record of, are listed alongside any retractions rather than quietly dropped, a screening pass that omits them reads as a clean bill of health when it isn't.
There's also renaming to your filename template, and a check for whether an abstract actually belongs to the PDF it's attached to (that one is reported, never repaired, either the abstract is wrong or the PDF is, and the plugin can't tell which).
Every run that changes something is journalled and can be undone per change, and writes a CSV listing every decision, including the items it couldn't match and why, which is the part you need when you come to write the methods section.
Please note that I am a third-party and unofficial. I'm the only maintainer.
Developed and tested against Zotero 9. The manifest allows 7.0 and up, but I have no Zotero 7 install to test on; if you're on 7, I'd genuinely like to hear whether it works.
Scanned PDFs with no text layer can't be matched on content; they fall back to filename similarity. Run OCR first. The dialog tells you how many files this affected.
It reads the first 3 pages of each PDF by default. Raise it in settings if your sources push the DOI onto page 2 or 3.
The initial implementation was generated with Claude, then debugged and hardened against a live library over a dozen releases.
Install
Download autoattach-1.0.1.xpi from the release below (right-click, Save link as, don't let the browser open it), then Tools > Plugins > gear icon > Install Plugin From File.
https://github.com/adolinjonathan-bot/zotero-toolkit/releases/tag/pdf-file-attacher-v1.0.1
Source and full documentation: https://github.com/adolinjonathan-bot/zotero-toolkit/tree/main/plugins/pdf-file-attacher
MIT licensed.
Feedback is welcome, particularly on Zotero 7 and on whether the confidence defaults (82% to auto-tick and 55% to offer) feel right on libraries that aren't shaped like mine.