Citations from a grounded LLM answer are part of the answer. They are not decoration, not a SEO-style footer, not optional. If your product is doing retrieval — RAG, web search, tool calls that fetch content — and not showing the user where the answer came from, you are asking the user to take the model on faith. Most users will not.

This article covers the three citation placements that work, the harder problem of keeping citations honest, and a few specific moves worth stealing from products that do this well.

What the citation needs to communicate

A good citation answers four questions in roughly this order of importance:

  1. Where did this come from? A clickable link to the source.
  2. Is it credible? The domain, the publication date, or whatever signal makes the source trustworthy.
  3. What specifically? The exact passage or chunk the model used, not just the whole article.
  4. Did the model actually use it? As opposed to "the retrieval system fetched it and the model ignored it."

Most citation UIs handle 1 well, 2 inconsistently, 3 rarely, and 4 almost never. The products with the highest user trust handle all four.

Placement 1: inline footnote markers

The Perplexity pattern. Small superscript numbers ([1], [2], [3]) inline at the end of the relevant sentence, linking to a numbered list of sources elsewhere on the page.

Strengths:

  • Low visual weight; the markers do not disrupt reading flow.
  • Citation density is visible at a glance — a paragraph with five markers signals heavily-sourced; a paragraph with none signals "this is my voice."
  • Familiar from academic writing; users intuit it immediately.

Weaknesses:

  • Click cost. Verifying a claim requires clicking the marker, jumping to the sources list, finding the right one. Adding hover-cards on top mitigates this (see Placement 2).
  • The marker is detached from the source content — the user has to do a small reading exercise to align them.

When to use: long-form factual answers with many sources. Web-search, RAG over documentation, research summaries.

Placement 2: hover-cards

A tooltip or popover that appears when the user hovers (or focuses, for keyboard users) on a citation marker. Shows the source title, the URL or domain, a short snippet from the cited passage, and often a "open source" button.

Hover-cards stack on top of inline markers — they are not an either/or. The marker gives location, the hover-card gives preview without a click.

Strengths:

  • Verification cost drops dramatically. The user can spot-check claims without leaving the answer.
  • The snippet inside the hover-card is the actual cited passage — the closest thing to "show me what the model used."

Weaknesses:

  • Hover does not exist on touch devices; needs a tap-to-toggle fallback.
  • Easy to over-design. A 400px hover-card with five fields and a screenshot is worse than a clean two-line preview.

Implementation note: position the hover-card so it does not block the next sentence the user was about to read. Anchor below the marker when there is room; flip above when there is not.

Placement 3: sticky sources panel

A persistent panel — usually right side, sometimes below the answer — that lists every source the answer touched, with the cited passages and links to the originals.

Used by some answer-engine UIs for research-heavy queries (Bing's AI answer experience has historically leaned this way, though the exact layout evolves), most legal-research products, and internal RAG tools where compliance demands traceability.

Strengths:

  • The user can see the whole evidentiary base at once. Good for "is the answer well-sourced?" judgments.
  • Supports workflows where the user is going to verify every claim anyway (legal, medical, compliance).
  • The panel can hold richer information: full chunks, document type, retrieval rank, even the model's confidence per chunk.

Weaknesses:

  • Visual real estate. The answer column gets narrower.
  • Most users do not need this. For everyday Q&A it is overkill.

When to use: high-trust workflows where verification is part of the user's job. Not for general consumer products.

The harder problem: keeping citations real

Placement is the easy part. The hard part is making sure the citation actually supports the claim. Two specific failure modes that show up often:

The retrieval was bad. The retrieval system returned a chunk that looks relevant but actually does not answer the question. The model writes a plausible answer using the chunk's general topic, attaches the chunk as a citation, and the citation looks fine until someone reads the source. Fix this at the retrieval layer — better chunking, better re-ranking, hybrid retrieval — not at the UI layer. See How RAG Actually Works for the upstream design choices.

The model misattributed the claim. Retrieval returned three chunks; the model wrote an answer that synthesized across them; the model attached chunk [1] to a sentence whose actual support is in chunk [2]. This shows up especially with multi-document RAG and with models that are eager to cite generously.

The defensive move is post-hoc verification. After the answer is generated, for each cited claim, run a cheap verification call: "Does this passage support this sentence? Answer yes or no." Drop or visually flag citations that fail the check. The verification step costs a small fraction of the answer-generation step and meaningfully cuts misattributed citations.

This is not a perfect filter — verification is itself an LLM call and has its own error rate — but it catches the largest category of bad citations (citation attached to wrong chunk) at low cost.

Specific moves worth stealing

A short catalog of patterns that have shown up across multiple shipped products. Specific UIs evolve faster than the patterns themselves, so treat these as ideas to evaluate against the live product rather than as descriptions of any one screen.

  • Favicon row above the answer. A horizontal strip of source favicons before the user reads anything, signaling "this answer is grounded in N specific sources." Popularized by Perplexity; widely copied. Sets expectations and shows credibility at a glance.
  • Restrained default, rich on demand. Citation markers are clearly clickable; hover-cards show source plus snippet; a full sources panel appears only when expanded. The Claude web-search experience and several research products have leaned this way. Avoids overwhelming users who do not need the detail.
  • Sources tab as a peer to the answer, rather than a footer. Switching to it does not lose the user's place. Used in answer-engine UIs where users routinely cross-check.
  • Surfacing retrieval rank and score for power users. Knowing not just what was cited but how confident retrieval was in each chunk is useful for debugging RAG and for trust calibration in compliance-heavy contexts. Usually hidden behind a power-user toggle.

The minimum viable citation UI

If you are starting from scratch and want the cheapest credible implementation, ship this:

  1. Inline numbered markers at the end of each claim that came from retrieval.
  2. A list of numbered sources below the answer with title, domain, and link.
  3. Add hover-cards on the markers when you have time.
  4. Add post-hoc verification on the citations when you can afford the latency or are seeing misattribution complaints.

Skip the sticky panel until you have a use case that demands it. Skip retrieval-rank display unless your users are debugging the retrieval system. Skip "citation styles" that look like academic papers — your users are not writing footnotes, they are checking work.