Overview
How might we let people read the original passages beside the answer without losing their place in the thread?
When users need to verify retrieval in context
- Document Q&A, legal research, and RAG products where claims map to real passages.
- Dual-pane reading where people compare the answer and source continuously.
- Search answers where a full source list beats one-off citation previews.
- Any surface where trust depends on seeing the excerpt that grounded a claim.
When a browser pane would be empty theater
- Pure chat with no retrieval corpus, where a browser pane would be empty theater.
- Mobile chat where a persistent dual pane destroys reading space; prefer a slide-over Sources view instead.
- Creative generation tasks where “sources” would invent provenance.
States
Design the browse lifecycle, not only a footnote link that opens a new tab.
Answer ready
The synthesized answer is visible. A source count or chip shows that retrieval grounded the reply.
Panel closed
The answer uses full width. Sources stay one tap away via the chip or inline marks.
Panel open
A bottom sheet lists every source used for the answer over the reply.
Inspecting
Each row shows domain, title, and snippet so people can scan without leaving the product.
Linked
An inline citation or chip scrolls the panel to the matching source row or highlighted passage.
Dismissed
Closing the panel returns focus to the answer. Open state does not reset the thread.
Key UX elements
The parts that must be present for side-by-side verification to feel trustworthy.
Keep the synthesis readable on its own.
The reply stands alone. Sources augment it; they do not replace clear prose in the main pane.
Offer one obvious entry to all sources.
A favicon stack plus source count opens the sheet without hunting footnotes.
Label what the list covers.
Show source count and the query or topic so people know which answer the list belongs to.
Make each source scannable in place.
Domain, title, and excerpt on every row. Links open externally; inspection stays in-product first.
Let people dismiss without losing the answer.
A clear close control returns to reading. Do not auto-open full width on every new query.
Anti-patterns to avoid
Listing file names without showing the excerpt that grounded the claim.
Highlights that do not match the cited sentence, training users to distrust the panel.
Auto-opening a full-width browser that pushes the answer off-screen on every query.
No jump-to-passage link from an inline citation chip into the browser.
How products use it
| Product | Implementation |
|---|---|
| ChatPDF / document Q&A tools | Keeps the PDF open beside answers and scrolls to cited pages. |
| Perplexity | Sources panel and previews support claim-level inspection beyond chat text. |
| Notion AI / enterprise RAG | Opens linked workspace pages or snippets that the answer drew from. |
| Legal research platforms | Dual-pane reading of opinions or filings next to AI summaries. |
Real-world examples
How shipped products implement source browser, from our teardown guides.
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Source Browser" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is a source browser in AI products?
A source browser is a side panel or dual-pane view of the documents or passages the model used, often with highlights tied to claims in the answer so users can verify context without leaving the product.
How does a source browser relate to citations?
Citations mark which claim maps to which source. The source browser is where users go after clicking a citation to read the underlying passage. Strong trust UX usually needs both.
When is a full dual-pane better than a sources list?
Use dual-pane for document-heavy work (contracts, PDFs, codebases) where users compare answer and source continuously. Use a compact list or drawer for web search answers on small screens.