How to Use XML Tags to Structure AI Prompts

XML tags are plain markers like <context> or <instructions> that you wrap around different parts of a prompt so a model can tell them apart. Instead of one long paragraph that blends background information, rules, an example, and the actual request together, you split the prompt into labeled sections. Anthropic's prompt engineering documentation for Claude recommends this directly: tagged sections help the model parse complex prompts unambiguously, especially once a prompt mixes instructions, context, examples, and variable input. The gain shows up most in prompts with several moving parts, where a plain paragraph forces the model to guess which sentence belongs to which job.

The same prompt, written two ways

Take a common task: a model that drafts replies to customer support tickets for a project management app. The prompt needs to carry the model's role, the response rules, a sample of a good reply, and the actual ticket text. Here is that prompt written the way most people write prompts, as one running paragraph.

You are a support agent for Fern, a project management app. Customers write in about missing features, bugs, and billing issues. Keep responses under 150 words, friendly but not overly casual, never promise release dates, and always ask one clarifying question if the issue is unclear. Here is an example of a good response: Thanks for flagging this, we don't have recurring tasks yet but it's a popular request, can you tell me if you need daily, weekly, or custom recurrence? Now respond to this ticket: Hey, I can't figure out how to invite my team members, is this even possible?

Nothing marks where the role ends and the rules begin, or where the sample reply stops and the real ticket starts. A model reading this has to infer structure from sentence position and the word now, which works most of the time and fails exactly when it matters, on a longer or oddly worded ticket. The sample reply about recurring tasks also sits right next to the real ticket about team invites, close enough that a rushed or smaller model can blend details from the example into its actual answer.

Here is the same information broken into tagged sections.

<context> You are a support agent for Fern, a project management app. Customers write in about missing features, bugs, and billing issues. </context>

<instructions> Keep responses under 150 words. Friendly but not overly casual. Never promise release dates. Always ask one clarifying question if the issue is unclear. </instructions>

<example> Thanks for flagging this, we don't have recurring tasks yet but it's a popular request. Can you tell me if you need daily, weekly, or custom recurrence? </example>

<ticket> Hey, I can't figure out how to invite my team members, is this even possible? </ticket>

Each tag now marks exactly one job. The model does not need to infer where background information ends and the request starts, it can go straight to the ticket tag for the actual task and treat context, instructions, and example as separate reference material. A reply is also less likely to borrow details from the sample, since the sample sits in its own container instead of running directly into the real ticket.

When this earns its keep

A one-line prompt like summarize this email does not need tags, there is only one job to do. Tags pay off once a prompt does several things at once: set a role, state rules, supply an example, and hand over the actual input, all in one message. That combination shows up constantly in production prompts, from support responders to code review assistants that get a diff plus a style guide. If the role and rules are meant to persist across many conversations rather than one message, they usually belong in a system prompt instead, but the same tagging habit still applies inside it.

The same logic applies when a prompt hands an AI coding agent a mix of source files, a style guide, and a task description. Wrapping each piece in its own tag keeps the agent from confusing the file it is editing with a document that only holds reference conventions, the same discipline behind handing an agent a design system to follow.

Practical tips for using XML tags in prompts

A few habits keep tagged prompts effective instead of just decorative.

• Use plain, descriptive tag names for what they hold, such as context, instructions, examples, or data. Skip generic names like section1.

• Close every tag you open. An unclosed tag can make the model treat everything that follows as part of that same section.

• Keep tag names consistent within one prompt. Switching between example and sample partway through undoes the clarity you were going for.

• Number repeated sections instead of reusing one tag, such as example_1 and example_2, rather than three separate example blocks.

• Save the technique for prompts that genuinely mix multiple kinds of content. Wrapping a single short instruction in tags adds noise without adding clarity.

One more use worth calling out: a thinking tag around reasoning steps, kept separate from an answer tag around the final output, is a clean way to let a model work through a problem before it responds, the same underlying idea as chain of thought prompting, applied through tags.

Frequently asked questions

Do XML tags need to be valid XML?

No. The model treats them as text markers, not markup parsed by an XML library. Consistent open and close tags are enough.

Does this work with models other than Claude?

Most current large language models handle tagged sections better than dense paragraphs, since the pattern gives the model a clear boundary to attend to. Claude's documentation is the most explicit about recommending it, but the underlying benefit applies broadly.

Can I combine XML tags with Markdown headings?

Yes, they solve different problems. Headings help a person skim a document, tags mark boundaries for the model to parse. Many prompts use tags for the model-facing structure and keep headings for anything a person will also read.

How many tags is too many?

If a prompt needs more than five or six top-level tags, it is usually doing too many jobs at once. Split it into a separate call per job, or trim it down to only the sections that specific step actually needs. For more ways to tighten prompts like this, see our broader guide to prompt engineering fundamentals.