The Practical Guide to XML Prompt Engineering for Claude

If you've been working with Anthropic's Claude, you might have noticed a recurring recommendation in their prompt-engineering docs: using XML tags. But when should you actually use them, and when are they just getting in the way?

Claude XML isn't actual, validated XML. It’s a practical convention of wrapping parts of a prompt in named tags—like <instructions>, <context>, <example>, and <document>—so Claude can reliably distinguish the role of each section. Because Claude was trained on prompts formatted this way, it's highly effective for resolving structural ambiguity.

Here is a breakdown of when to use it, when to avoid it, and some practical patterns to get you started.

When XML Actually Helps (And When It Doesn't)

You don't need XML for everything. In fact, slapping tags on every prompt wastes tokens and adds visual noise. The golden rule: XML helps when your prompt mixes instructions, context, examples, and variable inputs.

Here are the key scenarios where XML pays for itself:

• Repeatable work at scale: Running the same prompt against varying user inputs.
  
  
• Structured output: When you need extraction or classification that downstream code will parse.
  
  
• Long, mixed prompts: When system instructions, retrieved documents, few-shot examples, and a question all live in one massive message and need clear boundaries.
  
  
• Untrusted-input boundaries: Wrapping user data so prompt injection attempts become more visible in your logs.
  
  
• Multi-artifact outputs: Requesting a draft, a critique, and a final version in one API call. Separate output tags make each piece easily parseable.
  
  

When It's Just Noise

Skip the tags if you are engaging in casual conversational chat, single-shot creative writing, or simple one-line lookups. Furthermore, you should avoid tags if a current API feature does the job better. For example, use Claude's native tool use for structured output rather than a <format> tag, and use the API's extended thinking feature rather than manually writing <thinking> tags (using both can actually cause them to fight each other).

Working Examples: The 30-Second Starter

When you do need structure, the most useful pattern is separating your instructions, context, and the question.

Here is a basic, runnable example of classifying a support ticket:

XML

<instructions>
You are reviewing a customer support ticket. Classify the sentiment as
positive, neutral, or negative. Return only the label.
</instructions>

<ticket>
Hi — the new dashboard is so much faster. Thank you for shipping this.
</ticket>

Classify the sentiment of the ticket above.

Scaling Up: Advanced Prompt Patterns

As your tasks get more complex—such as incorporating Retrieval-Augmented Generation (RAG), multi-document analysis, or agentic tool use—you can scale this XML pattern up. Here is a one-shot pattern providing context and examples:

XML

<instructions>...</instructions>

<context>
The user is a senior engineer asking about distributed systems.
Prefer technical depth over surface explanation.
</context>

<examples>
  <example>
    <input>What is a quorum?</input>
    <output>A quorum is the minimum number of nodes that must agree...</output>
  </example>
</examples>

<question>Explain the CAP theorem in 100 words.</question>

Anti-Patterns: What to Avoid

Mistakes in XML prompting might look fine to the human eye but can quietly degrade Claude's reliability. Always avoid:

• Over-tagging: Don't wrap every single sentence in a tag. If there is no structural ambiguity, drop the tags.
  
  
• Fighting API Features: As mentioned above, don't use inline <role> tags if you are already using the API system parameter for a persona, and don't mix <thinking> tags with the native extended thinking feature.