Claude citations: char_location, page_location and more

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. Your compliance tool sends three document blocks with citations: {enabled: true} and also sets output_config: {format: {...}} so the answer arrives as a fixed JSON object. Every request returns a 400 error, and both features work correctly when used alone. What is the most likely cause?

   Right. In the game that’s Renown for your Prompt Engineering, Structured Output and Retrieval building.

   Not that one: B is right. In the game your Prompt Engineering, Structured Output and Retrieval building would lose a little Renown, and this question would come back later.

   Your answerA.Citations require a beta header that the structured-outputs request is missing.Citations need no beta header — they are configured entirely by citations: {enabled: true} on each document block. Adding a header would not change the outcome, because the rejection comes from combining the two features.The answerB.Structured outputs and citations cannot be combined on the same request.Structured outputs and citations are mutually exclusive. Setting output_config.format on a request whose document blocks have citations: {enabled: true} returns a 400, so a design must choose either a schema-constrained response or grounded citations.Your answerC.Citations must be enabled on some but not all of the document blocks in a request.The citations setting is all-or-none across the documents in a request. Enabling it on a subset is itself invalid, and doing so would not make a schema-constrained response legal.Your answerD.Structured outputs require the documents to be uploaded through the Files API first.The Files API simply provides another source for a document block, referenced by file_id. It changes where the bytes come from, not whether a response schema may coexist with citations.

   Written from platform.claude.com/docs/en/build-with-claude/citations

2. Your compliance viewer highlights the source of every cited claim by scrolling a rendered PDF to the referenced page. You read the page_location object on each returned citation and need to map its values onto the viewer's page control. Which approach should you take?

   Right. In the game that’s Renown for your Prompt Engineering, Structured Output and Retrieval building.

   Not that one: B is right. In the game your Prompt Engineering, Structured Output and Retrieval building would lose a little Renown, and this question would come back later.

   Your answerA.Compute the scroll target from start_char_index, a character offset measured across the flattened document text.start_char_index and end_char_index belong to char_location, which is what a plain-text document produces. A PDF citation reports pages, not character offsets into a flattened string.The answerB.Scroll the viewer to start_page_number and highlight through end_page_number, since both page numbers are 1-indexed.A citation's location object is typed. For PDF sources the type is page_location, carrying start_page_number and end_page_number, which are 1-indexed.Your answerC.Read the citation's page_index, which is 0-indexed, and add one before passing it to the viewer's page control.There is no page_index field, and the page numbers that are returned already start at 1. Adding one to them would send the viewer to the page after the cited passage.Your answerD.Recover the page number by matching cited_text against the rendered PDF, since the citation carries only a block index.content_block_location is the location type for custom content blocks. A PDF citation carries explicit page numbers, so there is no need to re-derive the position by string-matching cited_text against the document.

   Show the full explanation and doc quotes

   Plain-text documents use char_location with character offsets, and custom content uses content_block_location.

   Written from platform.claude.com/docs/en/build-with-claude/citations

3. Your archive team enables citations on a batch of scanned historical PDFs that contain no embedded text layer. Claude describes the pages accurately, but no citation is ever returned for those files, while citations appear normally for the born-digital PDFs in the same batch. What is the most likely cause?

   Right. In the game that’s Renown for your Prompt Engineering, Structured Output and Retrieval building.

   Not that one: D is right. In the game your Prompt Engineering, Structured Output and Retrieval building would lose a little Renown, and this question would come back later.

   Your answerA.Citations were enabled on only some document blocks, so the scans were skipped.Citations must be enabled on every document block in a request or on none of them. A partial configuration is rejected rather than quietly ignored for some files.Your answerB.Scanned PDFs exceed the per-document page limit and are silently truncated.Page limits — 600 per request, or 100 when the context window is under 1M tokens — are enforced by rejecting the request. Content is not silently dropped.Your answerC.PDFs must be uploaded through the Files API before their pages become citable.PDFs can be supplied as base64, as a URL, or by file_id from the Files API, and all three are equally citable. The delivery route is not what determines citability.The answerD.Image citations are not supported, so a PDF with no extractable text is not citable.PDF citations are produced from extracted text chunked into sentences.

   Show the full explanation and doc quotes

   Only text citations are supported and image citations are not yet possible, so PDFs that are scans without extractable text cannot be cited even though Claude can still read the pages visually.

   Written from platform.claude.com/docs/en/build-with-claude/citations