Build citations before you write the prompt
Add page-level citations to PDF RAG answers by carrying source metadata through every stage: parsing, chunking, embedding, retrieval, generation, and display. Each retrieved chunk should know its document, page range, section, and source coordinates.
Do not ask the model to invent citations from text alone. Give it stable citation IDs that your application resolves after generation.
The citation object
{
"citation_id": "S2",
"document_id": "vendor-policy-v4",
"document_title": "Vendor Security Policy",
"section": "4.2 Encryption",
"pages": [12],
"source_elements": ["el_882", "el_883"],
"bbox": [[84, 302, 528, 386]],
"retrieved_text": "Customer data must be encrypted..."
}
The prompt receives S2 and the retrieved text. The application, not the model, turns S2 into a page link and highlight.
Start during parsing
Citations cannot be repaired at the final prompt if the ingestion pipeline discarded page context. Use DocuShell Parse PDF to retain page and bounding-box metadata alongside structured text.
When chunks are created, copy the source references into the chunk record. If a chunk combines several elements, keep all relevant references.
Use IDs instead of free-form references
Assign each retrievable chunk a short citation ID. Include that ID with the chunk text in the model context and instruct the model to cite only supplied IDs.
After generation, your application maps the ID to a human label such as “Vendor Policy, page 12” and a link that opens the correct page.
This prevents small formatting differences from breaking citation links.
Cite the evidence, not merely the document
A document-level link is weak when the source has 200 pages. A useful citation includes the page, section, and highlighted region where possible.
For a claim assembled from several sources, show several citations. Do not hide uncertainty by attaching one convenient page to a multi-part answer.
Validate support before release
A citation can be real and still fail to support the claim. Add a check that compares each generated statement with its cited chunk. High-stakes workflows should require human review for weak or conflicting evidence.
The hallucination risk guide explains why required citations work best alongside clean source text and restrained answer styles.
Design for the reviewer
Make citations easy to open. Preserve the reader's place, show the relevant region, and include enough surrounding content to understand exceptions.
The strongest PDF RAG experience is not the one with the most footnotes. It is the one where a skeptical reader can verify a claim in seconds.
A citation data model that survives generation
Give each retrieved source a stable ID such as S1 or S2 for the duration of the request. The model cites those IDs; the application owns the display label, URL, page number, and highlight geometry.
Keep the source ID separate from the chunk ID. One answer source may combine neighboring chunks from the same page, while one chunk may support several claims. Store the mapping in the response record so later audits see exactly what evidence the model received.
Claim-level citations beat paragraph-level link piles
Place citations immediately after the claim they support. A list of five sources at the bottom makes it hard to tell which source establishes which statement.
When a sentence includes two factual claims supported by different pages, split the sentence or cite both. When a source only suggests a conclusion, use cautious wording instead of presenting it as direct evidence.
Test citation correctness
Your evaluation set should check four things:
- the cited source was actually retrieved
- the link opens the correct document version and page
- the highlighted region contains the relevant evidence
- the evidence entails the claim rather than merely sharing keywords
Track broken links and unsupported citations separately from answer accuracy. A correct answer with a wrong citation still damages trust.
| Citation failure | What the user sees | Root cause to investigate |
|---|---|---|
| Right claim, wrong page | Citation opens nearby content | Chunk-to-page mapping |
| Relevant page, unsupported claim | Keyword match without entailment | Retrieval or generation |
| Correct source, broken link | Viewer cannot resolve artifact | URL or permission lifecycle |
| Missing exception source | Answer is incomplete | Chunk boundaries or retrieval recall |
| Stale document version | Old policy cited confidently | Index filtering and version metadata |
Release gate: a citation is valid only when the linked evidence supports the nearby claim and the requester is authorized to view that evidence.
Start with citation-preserving chunk design, then use the RAG faithfulness evaluation guide to score support. For documents with tables, follow the PDF table extraction guide for LLMs so citations retain row and column context.
Frequently Asked Questions
Free Tool
PDF to JSON
Turn PDFs into structured, source-aware data for RAG, review, and automation.
Try PDF to JSONDocuShell Team
The DocuShell editorial group writes and maintains guides for everyday PDF workflows, with updates made when tool behavior or documented limits change. See our editorial standards for the process behind each article.
Focus: Citation-grounded RAG and document evidence pipelines
Questions or feedback? Get in touch.


