Screening papers without uploading them

A researcher can ask questions across up to 40 PDFs at once without sending a single file anywhere: parsing, embedding and search run in the browser tab. This page covers what the parser does with preprint PDFs, how to split a larger screen into batches, and where a small local model stops being enough.

Last updated:

The useful unit here is a folder you already curate, not a whole database. Forty PDFs at about 700 characters per chunk is a few thousand chunks, which embeds in about a minute on a laptop and stays searchable after the tab goes offline.

What the parser keeps from a preprint

Table 1 — preprint PDFs, assessed without optimism
ElementWhat comes throughWhat you do about it
Single-column body textIn order, with page numbers on every chunkNothing — a citation reads “page 6”
Two-column layoutUsually correct, with occasional column bleedSkim the cited passage before quoting it
Inline maths symbolsPartial: simple symbols survive as textRead the derivation in the source PDF
Equations rendered as imagesNothingScreenshot the equation yourself
TablesCell text in reading order, without the gridAsk for the page and read the table in the PDF
Reference listPlain text, so author names are searchableUseful for “which paper cites X” questions
Supplementary CSVParsed row-wise, so a question can target a columnImport it alongside the PDF

Questions a literature pass answers well

  1. “Which of these papers train on fewer than 10,000 examples?” — works when the number is written out in the text.
  2. “Where does this paper state its main limitation?” — limitation paragraphs reuse the paper’s own vocabulary, so they rank high.
  3. “Which papers compare against the same baseline?” — an exact-token match on the baseline name, which vector search alone tends to smear.
  4. “What evaluation metrics appear across this set?” — returns the metric mentions with file and page; you assemble the table.
  5. “Is there any mention of a replication study?” — with strictness set to documents only, an empty result is itself a usable finding.

Splitting a 200-paper screen into batches

01

Group by sub-topic instead of alphabetically

Forty papers that share vocabulary retrieve far better than forty unrelated titles, because a question about a baseline gets real competition among neighbours.

02

Name your batches in your own notes

One library lives per browser profile. Keeping “topic-a”, “topic-b” and “methods” as separate passes means a question is scoped by whatever you loaded, so track which pass you are in.

03

Export before you clear

Save the question list and citation sets to CSV or Markdown before clearing site data to make room for the next forty. The export is plain text and stays readable.

04

Re-check every claim at the PDF

Each retrieved passage carries a file name and a page number. Verify there, not at the summary paragraph.

Where a local model is not enough

  • Cross-paper synthesis. The generation tier runs a 0.5B–1.5B model at 4-bit on your device. It can stitch three retrieved passages into a sentence; it cannot hold a 200-paper field in view.
  • Non-text evidence. A result expressed only as a figure, an image-based equation or a colour heat map is invisible to a text pipeline.
  • Scan-only material. Older scanned journals without an OCR layer produce no text, and the parser says so instead of indexing nothing.
  • Mathematical verification. The tool finds where a proof is written. It does not check the proof.
On authorship: The generation tier is a reading aid. Using it to produce text you submit as your own, or to paraphrase sources without attribution, is a matter for your institution’s rules — running locally does not change how the work is judged.

When this is not the right approach

  • You need to search a field, not a folder. There is no remote corpus: only the files you imported are searchable.
  • Two collaborators must query the same live index. The index lives in one browser profile and is never synchronised.
  • The screening set is bigger than 40 files or 200 MB and cannot be meaningfully split by topic.
  • The evidence you need is in figures, scanned pages or typeset maths.
  • You need a reviewable, timestamped log of what was searched. Nothing is logged, by design.
  • The question demands arithmetic over many papers, such as pooling sample sizes. Retrieval returns passages; the summing is yours.

Models, offline use and what leaves the machine

  • English libraries: all-MiniLM-L6-v2 at about 23 MB. Chinese libraries: bge-small-zh-v1.5 at about 25 MB. Mixed-language sets: multilingual-e5-small at about 120 MB.
  • The optional generation tier downloads Qwen2.5 0.5B–1.5B at 4-bit, 400 MB to 1.0 GB, and only after you click to confirm.
  • One outbound request ever: the first GET for model weights, carrying the file name. Afterwards the tool works offline.
  • No account and no tracking pixels, so there is nothing to attach a half-finished review to.
  • Per-library ceiling: 40 files, 25 MB each, 200 MB total, 20,000 chunks.
Can I search my whole reference manager at once?

Not through this tool. A library holds at most 40 files, so a full corpus has to be worked in batches you define.

Does it handle LaTeX source or arXiv HTML?

HTML and plain text are supported formats, so an arXiv HTML export is parsed. LaTeX source is plain text too, but macro-heavy files produce noisy chunks.

Will it extract a numbers table across papers?

It will retrieve each mention with its page, and the optional generation tier can arrange them into a list. The numbers themselves should be transcribed by you; a small local model misreads digits more often than it misreads prose.

What happens with two-column PDFs?

Reading order is usually right but not guaranteed. When a citation looks scrambled, check the passage in the PDF before quoting; the page number in the citation makes that quick.

Can I use it on a machine with no GPU?

Yes. Embedding and retrieval are CPU work. Only the optional generation tier benefits from WebGPU through WebLLM; on CPU expect roughly 3–8 tokens per second.