Table of Contents
You write Claude a detailed prompt with background, instructions, an example of what you want.
It still answers the wrong part first.
Or it mixes your example in with your actual request, and you end up rewriting the same prompt three times just to get it to focus on the right thing.
Here’s the good news: that’s not a Claude problem. It’s a structure problem.
Learning how to use XML tags in Claude prompts fixes it almost immediately, because tags tell Claude exactly where one idea ends and the next begins — instead of leaving it to guess.
This post shows you exactly how, with real examples you can copy straight into your own prompts.
Why Responses Get Messy Without XML Tags in Claude
A plain-text prompt asks Claude to do two jobs at once.
First, figure out the structure of your input. Then, respond to it.
The more parts your prompt has, the harder that first job gets.
Say your prompt includes a customer email, your product details, and instructions for a reply — all typed out as one long paragraph.
Claude has to infer where the email ends and your instructions start. Sometimes it gets that wrong, responding as if your instructions were part of the email itself.
That’s not random. It’s what happens when the input is ambiguous.
Fix the structure, and the guessing disappears.
What XML Tags in Claude Actually Do
XML tags are simple labels that wrap around a piece of text, like <email> and </email>.
Claude was trained extensively on prompts written this way. So it treats tagged content as a distinct, labeled unit — not one long stream of text it has to parse on the fly.
Think of it like a messy desk versus a filing cabinet.
A pile of documents forces you to dig through everything to find what you need. The same documents in labeled folders let you go straight to the right one.
Tags do that for Claude.
There’s no official list of “correct” tag names, either. <document>, <instructions>, <example>, <tone> — any descriptive name works, as long as you stay consistent with it inside the same prompt.
How to Use XML Tags in Claude (Step-by-Step)
Once you know what tags do, using them comes down to a few small habits.
Start by identifying the distinct parts of your input.
Before you write anything, mentally list the separate pieces in your prompt. Most break down into two to four: background information, the content to work on, instructions, and sometimes an example of the output you want.
Then wrap each part in a tag that describes what’s inside it.
Skip generic names like <text>. Use something specific, like <customer_review>. A descriptive name tells Claude what it’s looking at before it even reads the content.
Reference the tags directly in your instructions.
Naming a tag isn’t enough on its own. “Summarize the content inside <customer_review> in two sentences” works far better than a generic “summarize this.”
Test the prompt, and refine the names if something’s off.
If Claude misreads which section is which, the tag name is usually too vague. Swap <info> for <shipping_policy> and run it again.
Using Nested XML Tags for Multi-Part Prompts
Some prompts have more moving parts than that — multiple documents, several examples, separate instructions for different sections of the output.
That’s when it helps to nest tags inside other tags, so Claude understands a piece of content belongs to a larger group rather than standing alone.
Say you’re asking Claude to compare three customer reviews. Instead of giving each one an unrelated tag, group them together:
<reviews>
<review id="1">Shipping was slow but the product itself is great.</review>
<review id="2">Arrived on time, exactly as described.</review>
<review id="3">Packaging was damaged, product was fine.</review>
</reviews>
<instructions>
Identify the most common theme across the reviews in <reviews>.
</instructions>
That structure tells Claude the three reviews belong together and should be read as a set — not as three unrelated inputs.
The nesting itself carries meaning. It’s not just visual tidiness.
This shows up a lot in long-form content review, where you might have a <draft> tag containing several <section> tags, each one a part of an article you want edited individually.
What Tagged Prompts Actually Look Like
It helps to see the difference side by side.
Say you’re asking Claude to summarize a piece of customer feedback and draft a reply. Typed the way most people naturally write it, the prompt looks like this:
“Summarize this customer feedback and write a reply. The product arrived two days late and the box was damaged. I’ve ordered from you three times and this is the first issue I’ve had. Please make the reply apologetic but not overly formal, and offer a discount code.”
Claude has to figure out, on its own, where the feedback ends and the reply instructions begin. In longer prompts, that’s exactly where things get mixed up.
Now compare that to the same request with the feedback and the instructions separated into their own tags:
<customer_feedback>
The product arrived two days late and the box was damaged. I've ordered from you three times and this is the first issue I've had.
</customer_feedback>
<instructions>
Summarize the feedback in one sentence. Then write a reply that is apologetic but not overly formal, and includes a discount code.
</instructions>
There’s no ambiguity left. Claude knows exactly what to summarize and exactly what the instructions are, because each piece has a clear boundary around it.
The same idea works well when you’re feeding Claude an example alongside new content — common in product copywriting:
<product_description_example>
Handwoven cotton throw blanket. Soft, breathable, and made to last through daily use. Machine washable.
</product_description_example>
<product_details>
Ceramic mug, hand-glazed, holds 12oz, dishwasher safe.
</product_details>
<instructions>
Write a product description for the item in <product_details> that matches the tone and length of <product_description_example>.
</instructions>
This is especially handy for Shopify listings, where keeping the tone consistent across dozens of products matters.
If you’re building product copy this way, the [Shopify Product Descriptions] guide covers the tagging approach in more depth.
Common Mistakes When Using XML Tags in Claude
A few things tend to trip people up once they start tagging prompts.
Vague tag names. <data> or <text> tells Claude nothing about what’s actually inside. Name tags after the content, not the format.
Unclosed tags. Every <tag> needs a matching </tag>, or Claude may read the rest of the prompt as part of that section.
Nesting without a clear hierarchy. If tags go inside tags, the nesting should reflect the real relationship between the parts — a <review> living inside <all_reviews>, not the other way around.
Tagging without referencing the tags. Claude can’t connect the dots on its own. Your instructions need to name the tags directly.
Overloading a single tag. Cramming your background info, instructions, and example all into one <info> tag defeats the purpose. Each distinct idea deserves its own tag, even if that means your prompt ends up with five or six of them instead of one.
If your outputs are still inconsistent after cleaning all this up, the issue might run deeper than tagging alone. The [Claude Generic Output Fix] post covers the other common causes of vague, generic responses.
Once your prompts are tagged correctly, but you’re rebuilding the same structure over and over for different business tasks — that gets old fast.
The JSON Prompt Mastery for Claude product gives you 70+ pre-built structured prompts organized by business workflow, so you run the prompt and get the output without building anything from scratch.
When to Use XML Tags vs Plain Instructions
Not every prompt needs this.
A simple, single request — something like “write a three-line product tagline for a ceramic mug” — doesn’t gain much from XML structure. There’s only one part to the prompt in the first place.
Tags start earning their keep once a prompt has more than one distinct component: a document plus instructions, an example plus new content, or background context plus a task.
According to Anthropic’s own documentation on prompt engineering, XML tags help Claude parse prompts more accurately when multiple pieces of information are involved — exactly the scenario where plain-text prompts tend to fall apart.
A simple rule of thumb: if you can point to two or more “parts” in your prompt, it’s worth tagging them.
Claude gives inconsistent answers when it has to guess where your input ends and your instructions begin.
XML tags fix that by giving every part of your prompt a clear, labeled boundary. No guessing required.