Input Format

Structure the model can see

Providing context covers marking the boundary between your instruction and someone else's document, and quotes Anthropic on XML tags for exactly that. This page is the wider question: the structure of the whole payload, and whether the markup you choose changes anything.

It does, and by less than the internet suggests.

Pick a markup and use it consistently

Three conventions are in common use, and the honest summary is that consistency matters more than the choice.

XML-style tags are what Anthropic documents, and they read well when a prompt mixes several kinds of content. <instructions>, <context>, <examples>, <input> each say what they hold.

Markdown headings suit prompts that are mostly prose with sections. They are also what most models saw enormous amounts of during training, which is a reasonable argument for them.

JSON is precise and awkward to read, and it forces you to escape content that contains quotes. Reach for it when the payload is data rather than instructions.

The failure is mixing them. A prompt with a markdown heading, an XML tag and a JSON blob describing the same three sections gives the model three competing signals about where the boundaries are.

Ordering, and the two positions that get read

Where something sits in the prompt affects whether it is used. Long context processing covers the research: performance is strongest when relevant information is at the beginning or the end, and degrades in the middle.

Two practical consequences.

Put long documents early. Anthropic's guidance for long inputs is to lead with them and put the question afterwards. Image understanding notes the same ordering for images, which come before text.

Put the actual instruction last. After the material, immediately before the model starts generating, is the strongest position for what you want done.

The layout that follows is unglamorous and works: documents, then examples, then the task.

Label the parts

Whatever markup you pick, name each section for what it is rather than leaving the model to infer from position.

Two labels earn their tokens beyond the obvious. A source on each supplied document lets the model cite it and lets you check the citation, which providing context develops. And an explicit marker on untrusted content, saying it is material to read rather than instructions to follow, is one layer of the defence prompt injection says cannot be fully prevented.

Numbering repeated items helps too. Document 1, Document 2 gives you something to name in the question and in the answer.

Do not over-engineer it

Two habits waste effort.

Rebuilding the format per model. Provider guidance differs at the margins, and a clear, consistently structured prompt works on all of them. Tune the format when you have a measurement showing it matters, not because a blog post preferred tags.

Adding structure to short prompts. A three-sentence instruction wrapped in five XML tags is harder to read and no better. The structure pays when the payload has several parts that could be confused for each other.

Constraints makes the related point that format instructions are model-specific and expire. The same applies here: a format that helped one model version is not a permanent finding.

Measure it like anything else

If you think the markup matters for your task, that is a hypothesis with an easy test. Run your evaluation set with two formats and compare.

Most teams who do this find the difference small, and find the ordering change larger. That is useful to know before spending a day converting every prompt to XML.

Further reading

• Providing context: delimiters, sources, and the instruction-versus-data boundary.
• Long context processing: why position affects what gets read.
• Constraints: format control, and why it expires.
• Prompt engineering: the techniques in the order they pay.