From PDF Highlights to Obsidian Notes: Building a Research Reading Pipeline

Highlights trapped inside a PDF viewer are not notes. They are bookmarks that disappear from view the moment the tab closes. A reading pipeline that exports annotations into a linked note system turns reading into an accumulating knowledge base, where a paper's claims can be found again, connected to other work, and cited without reopening the PDF. The mechanics are less glamorous than the outcome: consistent annotation formats, stable citation keys, and a template that survives a thousand notes.

Choose an annotation format you can parse

Most readers export annotations as JSON, Markdown, or both. Zotero's built-in reader, for example, stores annotations as structured items with page number, color, comment text, and the highlighted quote. Obsidian's PDF plugins store annotations in a sidecar file.

Prefer the format that preserves four fields: the quoted text, the page number, the annotation comment, and a link back to the source. Color is useful as a lightweight taxonomy — yellow for claims, green for methods, red for contradictions — but only if the convention is documented somewhere you will actually read.

Export to Markdown with the quote as a blockquote and the comment beneath it. That structure renders cleanly in Obsidian, remains readable as plain text, and diffs well in version control.

Make citation keys stable before writing a single note

Every note needs a permanent identifier for its source. A citation key derived from author, year, and a short title slug is stable enough: vasquez2026-pdf-annotation. Store it in the note's frontmatter along with the DOI and a zotero:// link.

The key must never change, even if the paper is corrected or the title is edited. If the key changes, every backlink breaks. Derive it once at import and treat it as immutable.

Obsidian's frontmatter supports aliases, so a note can carry both the human title and the citation key without affecting link resolution.

The note template: summary, annotations, open questions, related

A workable note template has five parts: metadata block, one-paragraph summary in your own words, annotation sections grouped by theme, open questions, and a links section.

---
citekey: vasquez2026-pdf-annotation
doi: 10.0000/example
status: read
---
# {{title}}

> quoted text
> — p. 12

Grouping annotations by theme rather than by page order is what makes the note reusable. Page-order dumps reproduce the paper; thematic grouping produces something you can cite in a literature review.

Batch export without duplicates, and keeping the vault searchable

Reading twenty papers and exporting each individually is fine. Importing a folder of 200 PDFs requires a script and a duplicate check keyed on DOI. Before writing a note, query existing frontmatter for the DOI; skip if present, update annotations if the source changed.

Use a batch export that includes the paper's metadata, then run a normalization pass: strip trailing whitespace from quotes, merge adjacent highlights on the same page, and drop highlights shorter than a few words, which are usually accidental drags.

Annotations are only useful if search finds them. Add tags for method and topic at the note level rather than per highlight; too many tags makes the graph unreadable. Keep one index note per project with links to its papers, and use Obsidian's backlinks to discover which sources support which claims.

Run a periodic cleanup: notes with empty summaries, notes whose DOI no longer resolves, and notes with no outbound links. Those three checks keep the vault from becoming an archive of unread PDFs with decorative highlights.

Handling highlights that span pages

A highlight that crosses a page break exports as two blocks with an awkward split. Merge adjacent highlights when their page numbers differ by one and their text overlaps at the boundary. Without merging, a single quote becomes two bullet points and the citation looks like two sources.

Store the start and end anchors rather than only the page number. An anchor that includes a short text prefix and suffix lets you locate the highlight again after a re-export, even if the PDF was replaced with a corrected version.

Note structure for long-term retrieval, and where automation stops

A note per paper works until the library reaches a few hundred items and the graph becomes noise. At that scale, a hub note per project with links to papers, and a separate note per claim that links to multiple papers, makes the vault navigable.

Keep the paper note stable and append to it. Creating a new note for each reading session fragments the same paper across files and breaks backlinks.

Automate the mechanical part: export, frontmatter, citation key, quote formatting, duplicate detection. Do not automate the summary. A generated summary inserted into the vault becomes indistinguishable from your own notes after a few months, and you will eventually cite a claim you never verified.

If you use a model to suggest themes, keep its output in a clearly marked draft section that is deleted when you write the real summary.

Sync conflicts, and citation keys that survive a migration

Obsidian Sync and file-based sync services produce conflict files when two devices edit the same note. Annotation exports are append-heavy and conflict badly. Export on one machine, or write exports to a separate inbox folder that is merged manually.

Version the vault with Git if the notes matter. A conflict in a note is recoverable; a conflict in a folder of exported annotations is usually resolved by deleting both and re-exporting, which loses any manual edits.

If you move from one reference manager to another, the citation keys change unless you control them. Define the key format yourself in the reference manager's settings and disable automatic key generation. The vault's links depend on those keys staying identical across migrations.

A monthly maintenance pass, and linking annotations to the source

Check for notes whose DOI no longer resolves, notes with highlights but no summary, and notes with no outbound links. Those three checks keep the vault from becoming a storage unit for PDFs you will not reread.

Include the page number and a deep link in every exported block. An annotation without a locator is a quote you cannot verify later.

Use the PDF's own identifier in the link rather than a local file path. Local paths break as soon as the vault moves to another machine.