Citations and sources in AI answers: how to show where each fact comes from

What problem do citations solve?

A model can give a fluent, correct answer or a fluent, invented one, and both read the same. Without a reference, the person has to look up every fact on their own, and then the AI has not saved them any time. With a citation, verification costs one click.

Citations also change the relationship with the answer. Instead of asking the person to trust it, the answer shows its basis. This fits the principle of showing uncertainty: often the most useful signal is not a confidence percentage but “this comes from here”.

How do citations work in practice?

There are three common ways to get them, and it helps to know which one you are using, because each fails in a different way:

• Citations over documents you provide. The Claude API lets you enable citations on PDF, plain text and custom content documents. According to its documentation, the response returns the exact cited text and its location: a character range for plain text, a page number for PDFs or a block for custom content. Citations must be enabled on all documents in a request or on none, and they cannot cite images inside a PDF.
• Citations over web search results. Grounding with Google Search in the Gemini API connects the model to search and returns, along with the text, annotations that link each span of the answer (with its start and end position) to the source URL and title. That lets you place the citation mark right on the matching sentence.
• Citations by instruction. You ask the model to extract word-for-word quotes before answering, or to back each claim with a quote and remove any claim it cannot support. Anthropic’s guide to reducing hallucinations recommends extracting quotes first for long documents (over 20,000 tokens).

The difference matters. Anthropic explains that with the citations feature, pointers to the documents are always valid, because the API extracts the cited text directly. With citations by instruction, the model writes the quote as text, and it can copy it wrong or make it up. Also, with the citations feature the cited text does not count as output tokens, so it can be cheaper than asking the model to copy the passages.

A valid pointer does not mean the passage supports the sentence. The API guarantees the fragment exists in the document; it does not guarantee the model read it correctly.

There is a technical limit worth knowing: in the Claude API, citations cannot be combined with structured outputs (JSON with a schema). If you enable citations on a document and also request that format, the API returns a 400 error. If you need both, design the flow in two steps: first the cited answer, then the extraction to JSON.

Citations are the visible part of a larger pattern: RAG retrieves fragments from sources and the model answers with them. Without retrieval, citations are just text the model can invent.

How do you design them so people use them?

1. Anchor the citation to the sentence. A citation at the end of each paragraph is less useful than one attached to the specific sentence it supports.
2. Show the passage, not just the link. A link to an 80-page document forces a search. A box with the passage and its location lets people verify in seconds.
3. Use a stable format. A number, a short title and the location (“section 3, page 12”). Always the same, in every answer.
4. Do not open a new tab for every citation. A side panel or an expandable block keeps the conversation in place.
5. Show the source’s date. An old document may have been correct and no longer be. A date next to the citation lets people notice that without opening anything.
6. Say when there is no source. If the answer has no support, say so. “I did not find this in your documents” is better than a false citation.

What should you check before trusting a citation?

A citation helps, but it does not replace reading. Before using a cited answer for something important, check:

1. Does the passage say what the sentence claims? Compare the sentence with the full fragment, not only with a matching keyword.
2. Is a condition missing? A passage may have exceptions in another clause. Look for words such as “except”, “unless” or “starting from”, and for dates.
3. Is the source still current? A document from three years ago may have been correct then and be wrong today.
4. Does the answer cover everything you asked? An answer can cite correctly and still leave out an important case.

In design, this means keeping the full passage, the date and a link to the original document close at hand. That way the person can ask these questions without leaving the conversation.

What should you measure to know if citations work?

Three signals say a lot:

• Open rate. If almost nobody opens citations, first check whether they are visible and in the right place, before concluding nobody cares.
• Corrections after opening a citation. If the person opens the passage and then corrects or rephrases the question, the citation helped them catch a problem. That is good: it is the system working.
• “The citation doesn’t say that” reports. A button to flag that the passage does not support the sentence turns a silent error into data you can review.

Cross-check those numbers with user feedback to learn whether the system helps people verify or only looks rigorous.

When should you NOT use them?

When the answer is an opinion, a creative piece or a calculation with no external source, a list of citations suggests a backing that does not exist. It also makes no sense to cite something the person already knows and will not check: it only adds visual noise.

Example

Illustrative example: an assistant for a product team answers questions about supplier contracts. Each answer shows a number next to the sentence; tapping it opens the exact contract paragraph, with the clause and the signing date.

The person asks about the cancellation period. The answer says “30 days” with its citation. Opening the passage shows the clause says 30 days for new contracts and 60 for those signed before 2024. The citation was not false, but the answer was incomplete. Without the visible passage, the team would have taken it as true.

The team makes two changes. In the prompt, it asks the model to mention any exception in the cited passage. In the interface, it adds a “the citation doesn’t say that” button. To understand why the model trims information like this, read hallucinations.

Common mistakes

• Citing a link to the source’s home page instead of the exact section.
• Treating a citation as a guarantee of correctness.
• Confusing “the pointer is valid” with “the passage supports the sentence”.
• Showing citations that do not support the sentence, because the model summarized too much.
• Using a different citation format in every answer.
• Letting the AI invent a source when it does not have one.

Sources

• Citations (Claude documentation)
• Reduce hallucinations (Claude documentation)
• Grounding with Google Search (Gemini API documentation)