XML Escape
Convert reserved characters into XML entities so arbitrary text can be embedded safely.
Plain text
Escaped XML
Five characters are reserved in XML. Placing any of them into element text or an attribute value without escaping produces a document that no parser will accept — and, if the text came from user input, potentially an injection vulnerability.
This tool converts all five into their entity equivalents: & becomes &, < becomes <, > becomes >, " becomes " and ' becomes '. The ampersand is handled first so that already-escaped entities are not double-encoded incorrectly.
How to use the xml escape
- 1
Paste the raw text
Any text at all — a product description, an error message, a code snippet.
- 2
Escape
All five reserved characters are replaced with their named entities.
- 3
Embed the result
The output can be dropped directly into element content or an attribute value.
Escaping versus CDATA
For a short string, escaping is the right answer. For a long block containing many reserved characters — an embedded HTML fragment or a code sample — a CDATA section is more readable: <![CDATA[ … ]]>. Everything inside is treated as literal text with no escaping required.
CDATA has one trap: the sequence ]]> cannot appear inside it, since that terminates the block. If your content might contain it, escape instead.
Attribute values need care
Inside an attribute delimited by double quotes, a literal double quote must be escaped as ". Inside one delimited by single quotes, an apostrophe must be escaped as '. Escaping both, as this tool does, is always safe regardless of which delimiter you use.
XML Escape FAQ
Which characters actually have to be escaped?
Strictly, only & and < in element text, and additionally the quote character matching your attribute delimiter. Escaping all five is safe everywhere and is the conventional approach.
Is ' safe to use?
In XML, yes — it is one of the five predefined entities. In HTML 4 it was not defined, so if the output may be consumed as HTML, prefer the numeric form '.
Does this prevent XML injection?
Escaping untrusted text before inserting it into a document is the correct defence against content injection. It does not protect against XXE attacks, which are a parser configuration issue on the consuming side.