Workflow Playbook: Managing a Literature Review Without Uploading Unpublished Work

This is an illustrative workflow rather than a reported study or a measured result. It describes a pattern that recurs in research work: a large corpus of documents, a mix of formats and vintages, a need to search and organise all of it, and a genuine constraint on where the material can be sent.

The scenario: a doctoral researcher partway through a literature review, working with roughly two hundred papers. Some are recent PDFs downloaded from publisher sites. Some are scans of older print journals. A few are preprints and drafts shared privately, which may not be redistributed or uploaded anywhere. The task is to read efficiently, keep track of what has been read, and build a searchable working set.

Before any organisation is possible, the corpus has to be in a state where it can be searched, and that is not guaranteed.

A modern paper downloaded from a publisher has a real text layer: the characters are stored as text with positions, so search, selection, and extraction all work. A scan of a print journal does not. It is a photograph of a page, and searching it returns nothing, because there is nothing to search.

The distinction determines the workflow, and it is worth checking which category a document falls into before deciding what to do with it. Open the file and try to select a sentence with the cursor. If characters highlight cleanly, it has a text layer. If nothing selects, it is an image. Exporting a page as a picture with PDF to JPG makes this obvious at a glance, since the exported image and the visible page will be identical if the page is a scan.

For scanned papers, the prerequisite is optical character recognition, which produces a text layer from the image. Accuracy depends almost entirely on scan quality: a clean 300 dot per inch scan of printed text recognises well, while a skewed photocopy of a photocopy recognises poorly, and errors propagate into everything downstream. Always check the recognised output before trusting it, particularly for numbers, proper nouns, and anything you intend to quote.

Once the material is searchable, the problem becomes organisational, and it is the same problem as any document assembly task.

Reading bundles are the most useful structure. Rather than working with two hundred individual files, group them by theme, method, or chapter, and combine each group into a single working document with Merge PDF. A bundle of twenty papers on one theme is easier to navigate, easier to annotate consistently, and easier to revisit months later than twenty files scattered across a downloads folder.

Where a bundle is too large to work with comfortably, Split PDF extracts the relevant section of a long paper, which is common with conference proceedings where a single volume contains dozens of contributions. Extracting only what you need keeps the working set manageable and reduces the memory pressure of handling very large files in a browser tab.

For papers that need to be quoted or restructured, PDF to Word produces an editable document from the text layer. Be realistic about the result: extraction is reliable for single-column text, and considerably less so for two-column academic layouts, which is the standard format for most journals. The conversion guide explains what survives and what does not, and it is worth reading before you plan to convert a large batch.

Summarisation is the feature people want most in a literature review, and it is the feature with the most important caveat.

A language model cannot summarise a document it has not read. Any summarisation feature therefore has to get the text to a model. If the model runs on a server, the extracted text leaves your device. That is not a defect in the feature; it is what the feature is. But it means summarisation sits in a different category from merging or splitting, which never transmit anything.

Our own PDF Summarize tool works this way: the text is extracted locally in the browser, and then transmitted to a server-side endpoint that forwards it to a model provider. The same applies to the text cleanup step in the text extraction tool and to Translate PDF. We would rather state that plainly than make a blanket claim that everything stays on your device, because that claim would be false for these features.

The practical implication for a researcher is a decision, not a prohibition. For published papers that are already available publicly, sending text to a model is usually unremarkable. For preprints, drafts, embargoed manuscripts, and anything shared under a confidentiality expectation, it is not, and the right move is either to summarise manually or to use a workflow where the model runs locally. The privacy guide sets out the questions to ask of any tool with an AI feature.

There is a second limitation worth knowing about. Summaries are lossy in an unpredictable way. A summary tells you whether a paper is worth reading closely; it does not tell you what the paper says with any reliability, and it will occasionally compress away the specific detail you needed. Treat summarisation as a triage tool rather than a substitute for reading the sections you intend to cite.

Putting it together, the sequence separates local work from transmitted work.

The pattern here applies to any large corpus of mixed-vintage documents: legal discovery, archival research, due diligence, and technical documentation reviews all have the same shape.

The transferable elements are three. First, establish searchability before anything else, because an unsearchable corpus cannot be organised. Second, do the structural work locally, since merging, splitting, and organising have no reason to involve a server and are faster without one. Third, treat model-assisted features as a separate decision with a separate data flow, and make that decision per document rather than per corpus.

The third point is the one that is most often skipped, and it is the one with consequences. A workflow that quietly sends an entire corpus of confidential manuscripts to a summarisation service is a different proposition from one that sends three published papers, even though the button pressed is identical.