[HN Gopher] Why XML tags are so fundamental to Claude
___________________________________________________________________
Why XML tags are so fundamental to Claude
Author : glth
Score : 137 points
Date : 2026-03-01 14:52 UTC (8 hours ago)
(HTM) web link (glthr.com)
(TXT) w3m dump (glthr.com)
| TheJoeMan wrote:
| That first image, "Structure Prompts with XML", just screams AI-
| written. The bullet lists don't line up, the numbering starts at
| (2), random bolding. Why would anyone trust hallucinated
| documentation for prompting? At least with AI-generated software
| documentation, the context is the code itself, being regurgitated
| into bulleted english. But for instructions on using the LLM
| itself, it seems pretty lazy to not hand-type the preferred usage
| and human-learned tips.
| Calavar wrote:
| It looks like a screenshot from the Claude desktop app, so I
| don't think the author is trying to disguise the AI origin of
| the marerial
| rafram wrote:
| No, it's two screenshots from Anthropic documentation, stitched
| together: https://platform.claude.com/docs/en/build-with-
| claude/prompt...
|
| The post even links to that page, although there's a typo in
| the link.
| dmd wrote:
| They're not even stitched together ; there's just no padding
| between the two images.
| glth wrote:
| Author here: I have just fixed the typo. Thank you.
|
| And yes, these are screenshots from Anthropic's
| documentation.
| croes wrote:
| You just hallucinated the content is AI generated.
| michaelcampbell wrote:
| "This is AI" is the new "This is 'shopped, I can tell by the
| pixels."
| tingletech wrote:
| I can tell by the em dashes
| doctorpangloss wrote:
| There must be an OpenClaw YouTube video helping people post to
| hacker news, or something, because the front page is overrun
| with AI slop like this article, that makes no sense anyway. The
| author literally has no idea what any of this stuff means.
| wolttam wrote:
| Anthropic's tool calling was exposed as XML tags at the
| beginning, before they introduced the JSON API. I expect they're
| still templating those tool calls into XML before passing to the
| model's context
| pocketarc wrote:
| Yeah like I remember prior to reasoning models, their guidance
| was to use <think> tags to give models space for reasoning
| prior to an answer (incidentally, also the reason I didn't
| quite understand the fuss with reasoning models at first). It's
| always been XML with Anthropic.
| wolttam wrote:
| Exactly the same story here. I still use a tool that just
| asks them to use <think> instead of enabling native reasoning
| support, which has worked well back to Sonnet 3.0 (their
| first model with 'native' reasoning support was Sonnet 3.7)
| scotty79 wrote:
| Can you sniff it out with Wireshark?
| wolttam wrote:
| They don't expose the raw context over the wire, it's all
| pre/post processed at their API endpoints.
| imglorp wrote:
| A very minor porcelain on some of the agent input UX could
| present this structure for you. Instead of a single chat window,
| have four: task, context, constraints, output format.
|
| And while we're at it, instead of wall-of-text, I also feel like
| outputs could be structured at least into thinking and content,
| maybe other sections.
| Zebfross wrote:
| I thought the goal was minimal instruction to let Claude
| determine the best way to solve the problem. Not adding this to
| my workflow anytime soon.
| TheLNL wrote:
| It is not for the end user, it is more for things like wrappers
| and automation scripts.
|
| Nobody expects the end user to prompt the AI using a structured
| language like xml
| esafak wrote:
| This sounds like something for harnesses, not end users. Are they
| really expecting us to format prompts as XML??
| apwheele wrote:
| I think XML is good to know for prompting (similar to how
| <think></think> was popular for outputs, you can do that for
| other sections). But I have had much better experience just
| writing JSON and using line breaks, colons, etc. to demarcate
| sections.
|
| E.g. instead of <examples> <ex1>
| <input>....</input> <output>.....</output>
| </ex1> <ex2>....</ex2> ...
| </examples> <instructions>....</instructions>
| <input>{actual input}</input>
|
| Just doing something like: ...instructions...
| input: .... output: {..json here} ...maybe
| further instructions... input: {actual input}
|
| Use case document processing/extraction (both with Haiku and
| OpenAI models), the latter example works much better than the
| XML.
|
| N of 1 anecdote anyway for one use case.
| ekjhgkejhgk wrote:
| Could you clarify, do those tags need to be tags which exist
| and we need to lear about them and how to use them? Or we can
| put inside them whatever we want and just by virtue of being
| tags, Claude understands them in a special way?
| ezfe wrote:
| They probably don't need to be specific values. The model is
| fine tuned to see the tags as signals and then interprets
| them
| galaxyLogic wrote:
| If it walks like a duck ... AI thinks it is something like
| a duck.
| apwheele wrote:
| All the major foundation models will understand them
| implicitly, so it was popular to use <think>, but you could
| also use <reason> or <thinkhard> and the model would still go
| through the same process.
| cyanydeez wrote:
| <ponderforamoment>HTML is a large subsection of their
| training data, so they're used to seeing a somewhat
| semantic worldview</ponderforamoment>
| marxisttemp wrote:
| XML is much more readable than JSON, especially if your data
| has characters that are meaningful JSON syntax
| galaxyLogic wrote:
| I think readability is in the eye of the reader. JSON is less
| verbose, no ending tags everywhere, which I think makes it
| more readable than XML.
|
| But I'd be happy to hear about studies that show evidence for
| XML being more readable, than JSON.
| ezfe wrote:
| I disagree that XML is more readable in general, but for
| the purpose of tagging blocks of text as
| <important>important</important> in freeform writing, JSON
| is basically useless
| galaxyLogic wrote:
| XML helps because it a) Lets you to describe structures b) Make
| a clear context-change which make it clear you are not "talking
| in XML" you are "talking about XML".
|
| I assume you are right too, JSON is a less verbose format which
| allows you to express any structure you can express in XML, and
| should be as easy for AI to parse. Although that probably
| depends on the training data too.
|
| I recently asked AI why .md files are so prevalent with agentic
| AI and the answer is ... because .md files also express
| structure, like headers and lists.
|
| Again, depends on what the AI has been trained on.
|
| I would go with JSON, or some version of it which would also
| allow comments.
| michaelcampbell wrote:
| Total tangent, but what vagary of HTML (or the Brave Browser,
| which I'm using here) causes words to be split in very odd
| places? The "inspect" devtools certainly didn't show anything
| unusual to me. (Edit: Chrome, MS Edge, and Firefox do the same
| thing. I also notice they're all links; wonder if that has
| something to do with it.)
|
| https://i.imgur.com/HGa0i3m.png
| werdnapk wrote:
| CSS on the <a> tags:
|
| word-break: break-all;
| fancy_pantser wrote:
| CSS word-break property
| knallfrosch wrote:
| It's an error in the site's CSS. CSS has way better methods,
| like splitting words correctly depending on the language and
| hyphenating it.
|
| Although I can never remember the correct incantation, should
| be easy for LLMs.
| rosstex wrote:
| Ask Claude?
| twoodfin wrote:
| This isn't surprising: XML's core purpose was to simplify SGML
| for a wider breadth of applications on the web.
|
| HTML also descended from SGML, and it's hard to imagine a more
| deeply grooved structure in these models, given their training
| data.
|
| So if you want to annotate text with semantics in a way models
| will understand...
| tingletech wrote:
| XML and HTML are SGMLs
| ChrisSD wrote:
| HTML diverged from SGML pretty early on. Various standards
| over the years have attempted to specify it as an application
| of SGML but in practice almost nobody properly conformed to
| those standards. HTML5 gave up the pretence entirely.
| alansaber wrote:
| Sounds like as 1. XML is the cleanest/best quality training data
| (especially compared to PDF/HTML) 2. It follows that a user
| providing semantic tags in XML format can get best training
| alignment (hence best results). Shame they haven't quantified
| this assertion here.
| lsc4719 wrote:
| Makes sense
| kid64 wrote:
| The thesis here seems to be that delimiters provide important
| context for Claude, and for that putpose we should use XML.
|
| The article even references English's built-in delimiter, the
| quotation mark, which is reprented as a token for Claude, part of
| its training data.
|
| So are we sure the lesson isn't simply to leverage delimiters,
| such as quotation marks, in prompts, period? The article doesn't
| identify any way in which XML is superior to quotation marks in
| scenarios requiring the type of disambiguation quotation marks
| provide.
|
| Rather, the example XML tags shown seem to be serving as a
| shorthand for notating sections of the prompt ("treat this part
| of the prompt in this particular way"). That's useful, but seems
| to be addressing concerns that are separate from those
| contemplated by the author.
| jinushaun wrote:
| Except quotation marks look like regular text. I regularly use
| quotes in prompts for, ya know, quotes.
| wolttam wrote:
| The GP isn't suggesting to literally use quotes as the
| delimiter when prompting LLMs. They're pointing out that we
| humans already use delimiters in our natural language
| (quotation marks to delimit quotes). They're suggesting that
| delimiters of any kind may be helpful in the context of LLM
| prompting, which to me makes intuitive sense. That Claude is
| using XML is merely a convention.
| sheept wrote:
| XML is a bit more special/first class to Claude because it uses
| XML for tool calling: <antml:invoke
| name="Read">
| <antml:parameter
| name="file_path">/path/to/file</antml:parameter>
| <antml:parameter name="offset">100</antml:parameter>
| <antml:parameter name="limit">50</antml:parameter>
| </antml:invoke>
|
| I'm sure Claude can handle any delimiter and pseudo markup you
| throw at it, but one benefit of XML delimiters over quotation
| marks is that you repeat the delimiter name at the end, which
| I'd imagine might help if its contents are long (it certainly
| helps humans).
| Eric_WVGG wrote:
| bemused by how competently designed this is, compared to
| enshittified blogs and whatnot
|
| To be realistic, this design needs more weirdly sexual etsy
| garbage, "one weird tip," and "punch the monkey"
| CactusBlue wrote:
| I think the main advantage of the XML here is that the model is
| expected to have a matching end tag that is balanced, which
| reduces the likelihood of malformed outputs.
| RadiozRadioz wrote:
| > a contrast between Claude's modern approach [...] XML, a
| technology dating back to 1998
|
| Are we really at the point where some people see XML as a spooky
| old technology? The phrasing dotted around this article makes me
| feel that way. I find this quite strange.
| intrasight wrote:
| Yup. Kids these days...
| coldtea wrote:
| XML has been "spooky old technology" for over a decade now.
| It's heyday was something like 2002.
|
| Nobody dares advertise the XML capabilities of their product
| (which back then everybody did), nobody considers it either hot
| new thing (like back then) or mature - just obsolete enterprise
| shit.
|
| It's about as popular now as J2EE, except to people that think
| "10 years ago" means 1999.
| cyanydeez wrote:
| 20 years old means 1980!
| vlovich123 wrote:
| For me, even when it was first released, I considered
| obsolete enterprise shit. That view has not diminished as the
| sorry state of performance and security in that space has
| just reaffirmed that perception.
| himata4113 wrote:
| didn't know html was spooky tech, TIL. /s
| rhdunn wrote:
| XML is used a lot in standards and publishing industries --
| JATS, EPUB, ODF, DOCX/XLSX/..., DocBook, etc. are all XML
| based/use XML.
| michaelbarton wrote:
| Without being facetious, isn't HTML a dialect of XML and
| very widely used?
| Twisol wrote:
| HTML is actually a dialect of SGML. XHTML was an attempt
| to move to an XML-based foundation, but XML's strictness
| in parsing worked against it, and eventually folks just
| standardized how HTML parsers should interpret ill-formed
| HTML instead.
| vitejose wrote:
| No, HTML was historically supposed to be a subset of
| SGML; XML is also an application of SGML. XHTML is the
| XML version of HTML. As of HTML5, HTML is no longer
| technically SGML or XML.
| phlakaton wrote:
| HTML is far loosier-goosier in its syntax than XML
| allows. There was an attempt to nail its syntax down in
| the pre-HTML 5 days; that's XHTML. When HTML 5 pivoted
| away from that, that spelled the end of these two things
| ever coming together.
|
| Really, I think you can trace a lot of the "XML is
| deprecated technology" mindset to the release of HTML 5.
| That was when XML stopped being directly relevant to the
| web, though of course it still lives in in many other
| domains.
| graemep wrote:
| Also in finance. XBRL and FIXML although I do not know how
| widely used the latter is.
| eduction wrote:
| Obsolete enterprise shit I guess includes podcasting.
| Impressive for the enterprise.
|
| I'd be very curious what lasting open formats JSON has been
| used to build.
| girvo wrote:
| I kind of miss SOAP. Ahead of its time? Probably not, but I
| built some cool things on top of it
| pfraze wrote:
| atproto's lexicon-based rpc is pretty soap-like
| fc417fc802 wrote:
| It's not the hot new thing but when has hype ever mattered
| for getting shit done? I don't think anyone who considers it
| obsolete has an informed opinion on the matter.
|
| Typically a more primitive (sorry, minimal) format such as
| JSON is sufficient in which case there's no excuse to
| overcomplicate things. But sometimes JSON isn't sufficient
| and people start inventing half baked solutions such as JSON-
| LD for what is already a solved problem with a mature tech
| stack.
|
| XSLT remains an elegant and underused solution. Guile even
| includes built in XML facilities named SXML.
| mycall wrote:
| It makes me wonder how well an LLM like Opus can generate
| XSLT which was always the hard part when writing by hand.
| theowaway213456 wrote:
| The evidence suggests that XML was never that popular though
| for the general audience, you have to admit.
|
| For Web markup, as an industry we tried XHTML (HTML that was
| strictly XML) for a while, and that didn't stick, and now we
| have HTML5 which is much more lenient as it doesn't even
| require closing tags in some cases.
|
| For data exchange, people vastly prefer JSON as an exchange
| format for its simplicity, or protobuf and friends for their
| efficiency.
|
| As a configuration format, it has been vastly overtaken by
| YAML, TOML, and INI, due to their content-forward syntax.
|
| Having said all this I know there are some popular tools that
| use XML like ClickHouse, Apple's launchd, ROS, etc. but these
| are relatively niche compared to (e.g.) HTML
| icermann wrote:
| MS Office and Open-/LibreOffice are using zipped xml files
| (e.g. .docx, .xlsx and .odt). Svg vector graphics is xml, the
| x in ajax stands for xml (although replaced by json by now).
| SOAP (probably counts as the predecessor of REST) is xml-
| based.
|
| XML was definitely popular in the "well used" sense. How
| popular it was in the "well liked" sense can maybe be up for
| debate, but it was the best tool for the job at the time for
| alot of use cases.
| hbarka wrote:
| If you think XML is old tech, wait until you hear of EDI, still
| powering Walmart and Amazon logistics. XML came in like a
| wrecking ball with its self-documenting promise designed to
| replace that cryptic pesky payload called EDI. XML promised to
| solve world hunger. It spawned SOAP, XML over RPC, DOM, DTD,
| the heyday was beautiful and Microsoft was leading the charge.
| C# was also right around this time. Consulting firms were
| bloomed charged with delivering the asynchronous revolution,
| the loosely coupled messaging promises of XML. I think it
| succeeded and it's now quietly in the halls of warehouse having
| a beer or two with its older cousin the Electronic Data
| Interchange aka EDI.
| actionfromafar wrote:
| EDI is XML now.
| oytis wrote:
| XML is still around, but I don't think many people would choose
| it as a serialization format today for something new.
| dathanb82 wrote:
| The use of XML as a data serialization format was always a
| bad choice. It was designed as a document _markup_ language
| (it's in the name), which is exactly the way it's being used
| for Claude, and is actually a good use case.
| shams93 wrote:
| It has a number of security issues which have not been fixed
| which could be used for really interesting exploitation.
| WD-42 wrote:
| XML is back, everyone is rediscovering the terminal. Soon we'll
| discover that object oriented programming is good again.
| ixxie wrote:
| How about other frontier models, and smaller models?
| TutleCpt wrote:
| I think this article is 100% relevant to you today. Anthropic put
| out a training video, a number of months ago saying that XML
| should be highly encouraged for prompts. See
| https://m.youtube.com/watch?v=ysPbXH0LpIE
| strongpigeon wrote:
| This seems like an actual good use for XML. Using it as a
| serialization format always rubbed me the wrong way (it's super
| verbose, the named closing tag are unnecessary grammar-wise, the
| attribute-or-child question etc.) But to markup and structure LLM
| prompts and response it feels better than markdown (which doesn't
| stream that well)
| Lerc wrote:
| I am unconvinced.
|
| To me it seems like handling symbols that start and end sequences
| that could contain further start and end symbols is a difficult
| case.
|
| Humans can't do this very well either, we use visual aids such as
| indentation, synax hilighting or resort to just plain counting of
| levels.
|
| Obviously it's easy to throw parameters and training at the
| problem, you can easily synthetically generate all the XML
| training data you want.
|
| I can't help but think that training data should have a metadata
| token per content token. A way to encode the known information
| about each token that is not represented in the literal text.
|
| Especially tagging tokens explicitly as fiction, code, code from
| a known working project, something generated by itself, something
| provided by the user.
|
| While it might be fighting the bitter lesson, I think for
| explicitly structured data there should be benefits. I'd even go
| as far to suggest the metadata could handle nesting if it
| contained dimensions that performed rope operations to keep track
| of the depth.
|
| If you had such a metadata stream per token there's also the
| possibility of fine tuning instruction models to only follow
| instructions with a 'said by user' metadata, and then at
| inference time filter out that particular metadata signal from
| all other inputs.
|
| It seems like that would make prompt injection much harder.
| scotty79 wrote:
| Transformers look like perfect tech for keeping track of how
| deep and inside of what we are at the moment.
| thesz wrote:
| Transformers are able to recognize balanced brackets grammar
| at 97% success rate: https://openreview.net/pdf?id=kaILSVAspn
|
| This is 3% or infinitely far away from the perfect tech.
|
| The perfect tech is the stack.
| cyanydeez wrote:
| Basically, the only way you're separting user input from model
| meta-input is using some kind of character that'll never show
| up in the output of either users or LLMs.
|
| While technically possible, it'd be like a unicode conspiracy
| that had to quietly update everywhere without anyone being the
| wiser.
| ryanschneider wrote:
| Wait am I in the minority talking to Claude in markdown? I just
| assumed everyone does that, or at least all developers. It seems
| to work really well.
| cyanydeez wrote:
| I do that in openwebui for code indents like ```
| wooptoo wrote:
| Amazing how an entire profession that until yesterday would pride
| itself on precision, clarity (in thought and in writing),
| efficiency, and formality, has now descended into complete
| quackery.
| cyanydeez wrote:
| Are you talking about the office of the president of the united
| states?
|
| This vague posting is kind dumb.
| wooptoo wrote:
| It's a simple observation. I'm not here to win internet
| points. I've never before seen so much cargo-culting and
| mystic belief among engineers.
| spacecadet wrote:
| This has been the way for a long time, exploiting XML tags was a
| means of exfiltrating data or reversing a model for a while as
| well. Some platforms are still vulnerable to this.
| lmeyerov wrote:
| My intuition is it comes down to error-correcting codes. We're
| dealing with lossy systems that get off track, so including
| parity bits helps.
|
| Ex: <message>...</message> helps keep track. Even better?
| <message78>...</message78>. That's ugly xml, but great for LLMs.
| Likewise, using standard ontologies for identifiers (ex: we'll do
| OCSF, AT&CK, & CIM for splunk/kusto in louie.ai), even if they're
| not formally XML.
|
| For all these things... these intuitions need backing by evals in
| practice, and part of why I begrudgingly flipped from JSON to XML
| Jcampuzano2 wrote:
| But should this extend to anything that could end up in Claudes
| context? Should we be using xml even in skills for instance, or
| commands, custom subagents etc.
|
| And then do we end up over indexing on Claude and maybe this ends
| up hurting other models for those using multiple tools.
|
| I just dislike how much of AI is people saying "do this thing for
| better results" with no definitive proof but alas it comes with
| the non determinism.
|
| At least this one has the stamp of approval by Claude codes team
| itself.
| hkbuilds wrote:
| This matches my experience building AI-powered analysis tools.
| Structured output from LLMs is dramatically more reliable when
| you give the model clear delimiters to work with.
|
| One thing I've found: even with XML tags, you still need to
| validate and parse defensively. Models will occasionally nest
| tags wrong, omit closing tags, or hallucinate new tag names.
| Having a fallback parser that extracts content even from
| malformed XML has saved me more than once.
|
| The real win is that XML tags give you a natural way to do few-
| shot prompting with structure. You can show the model exactly
| what shape the output should take, and it follows remarkably
| well.
| kleyd wrote:
| The main benefit of using XML here seems to be that it forces
| clearer thinking and formulation from the user.
| TacticalCoder wrote:
| It'd be hilarious if XML schemas and validators were to make a
| comeback [1] to... interface with AI models.
|
| [1] well of course XML is still heavily used in stuff like
| interfacing with automated wire transfers with big banks (at
| least in Europe) and all the digital payments directives etc. But
| XML is not widely used by the "cool" stuff.
| muzani wrote:
| In the spirit of _Hacker_ News, a good way to learn about these
| tags is prompt injection and jailbreaking Claude.
|
| I'd post a link, but unfortunately many are highly NSFW. Just
| search for "Claude jailbreak" on reddit or something.
|
| You'll start to see how Claude really thinks. They'll put things
| in <ethic_reminders>, <cyber_warning> or <ip_reminder>. You could
| actually even snip these off in an API, overwrite them, or if
| your prompt-fu is good, convince Claude that these tags are
| prompt injections. It's also interesting noting how jailbreaking
| is easier on thinking mode because the jailbreaking prompts use
| these as evidence that Claude is trying to jailbreak itself.
|
| There's a lot of speculation in this thread, but go and have a
| spar with Claude instead.
___________________________________________________________________
(page generated 2026-03-01 23:00 UTC)