XML URL Encode Online — Encode XML for URLs

Percent-encode XML payloads for safe use in URL query parameters, SOAP-over-GET endpoints, and application/x-www-form-urlencoded bodies. Validates well-formedness first — 100% in your browser.

Input (XML document)

Output (percent-encoded)

What is XML URL Encoding?

XML URL encoding is the process of percent-encoding every URL-unsafe byte in an XML document so it can travel as a query parameter or form value. Angle brackets, ampersands, quotes, whitespace, and any non-ASCII byte all become %XX sequences. The result is plain ASCII text that fits inside any URL or application/x-www-form-urlencoded body.

SOAP-over-GET, SAML/XACML callbacks, legacy enterprise GET endpoints, and form uploads that ship XML all need this transformation. The OpenFormatter XML URL encoder validates well-formedness with DOMParser first, then runs encodeURIComponent — entirely on your machine, so credentials inside the envelope never leave the page.

How to URL-encode XML — 4 steps

Paste a well-formed XML document. A SOAP envelope, SAML assertion, or any fragment that parses cleanly.
Click Encode. The tool runs DOMParser to verify well-formedness, then encodeURIComponent for percent-encoding.
Inspect the output. Every < is now %3C, every & is %26, spaces are %20, and non-ASCII characters expand to UTF-8 multi-byte percent sequences.
Embed in a URL or form. Paste the encoded value after a parameter equals sign or into a form-urlencoded request body.

Side-by-side example

XML input

<soap:Envelope>
<soap:Body>
<getUser id="42"/>
</soap:Body>
</soap:Envelope>

Percent-encoded

%3Csoap%3AEnvelope%3E%0A%3Csoap%3ABody%3E%0A%3CgetUser%20id%3D%2242%22%2F%3E%0A%3C%2Fsoap%3ABody%3E%0A%3C%2Fsoap%3AEnvelope%3E

RFC 3986 Compliant

Encodes every byte outside the unreserved set (A-Z a-z 0-9 - _ . ~) — including all the URL-structural delimiters that would otherwise corrupt your query string.

Validates First

Runs DOMParser before encoding so a malformed document is rejected with a clear error rather than silently turning into a malformed percent string.

Client-Side Only

Validation and encoding run in your browser. SOAP envelopes, SAML assertions, and embedded credentials never reach a server.

Common use cases

check_circleBuilding SOAP-over-GET request URLs with the envelope as a query parameter
check_circleEncoding SAMLRequest or SAMLResponse parameters for IdP/SP redirects
check_circlePreparing XACML and WS-Federation state values for OAuth callback URIs
check_circlePosting XML payloads via application/x-www-form-urlencoded bodies
check_circleEmbedding diagnostic XML samples in deep-link URLs for support and debugging
check_circleRound-tripping XML through legacy enterprise GET-style APIs
check_circleEncoding XML for storage in URL-based query string analytics events
check_circleGenerating reproducible test URLs that carry sample XML payloads

URL encoding vs XML escaping — different layers

XML escaping protects characters that have meaning inside an XML document: < becomes < so a parser does not mistake it for a tag. URL encoding protects characters that have meaning inside a URL: < becomes %3C so a router does not mistake it for path/query syntax. They run at different layers — when you ship an XML document inside a URL, you typically apply XML escaping first (if the receiver parses the value as XML) and URL encoding always last.

Need to decode instead?

Reverse percent-encoding back to readable XML, or chain with our other XML tools — all browser-side.

XML URL Decode XML Formatter All XML Tools

Frequently Asked Questions

When do I actually need to URL-encode XML?

When the XML must travel inside the URL or an application/x-www-form-urlencoded body. SOAP-over-GET endpoints, SAML/XACML redirect parameters (SAMLRequest), legacy banking GET-style APIs, and form-based XML uploads all require percent-encoding so the angle brackets and ampersands do not collide with URL or form syntax.

Why does the tool validate the XML first?

A malformed document rarely gets healthier after percent-encoding — it just becomes a malformed encoded string. The tool runs DOMParser on your input first; if the parser flags a syntax error, encoding is blocked so you can fix the source. This catches mismatched tags, missing close brackets, and unbalanced quotes before they reach a server.

Should I XML-escape the content before URL-encoding?

Only if the receiver will parse the decoded value as a real XML document. In that case, your text content already needs & for & and < for <. URL encoding then escapes the whole thing again. If the receiver treats the value as an opaque blob, URL encoding alone suffices — XML-escaping a blob that nothing parses just adds noise.

What is the practical URL length limit?

Browsers vary, but most enforce a 2,000–8,000 character ceiling. After percent-encoding, every < / > / " / & costs three characters (%3C %3E %22 %26), so a small XML document can quickly exceed safe URL lengths. For payloads over a few hundred bytes, switch to a POST request with the XML as the body and use the appropriate Content-Type rather than a query parameter.

How does XML URL encoding differ from XML escaping?

XML escaping replaces < with < for use inside an XML document. URL encoding replaces < with %3C for use inside a URL. They produce different output for different contexts. URL encoding does not understand XML structure — it just escapes bytes. XML escaping respects element/attribute boundaries.

How are non-ASCII characters handled?

encodeURIComponent first converts each character to its UTF-8 byte sequence and then percent-encodes every byte. So é becomes %C3%A9 (two bytes), € becomes %E2%82%AC, and 🚀 becomes %F0%9F%9A%80 (four bytes). The output is always plain ASCII safe for any URL.

Why use encodeURIComponent and not encodeURI?

encodeURI assumes you are encoding a complete URL and leaves URL-structural delimiters (?, &, /, #, etc.) untouched. That is the wrong behaviour for XML embedded in a parameter — a literal & inside the XML would survive encoding and the receiving server would misparse the query string. encodeURIComponent escapes those delimiters too, which is exactly what an XML parameter value needs.

Is my XML uploaded to a server?

No. Validation and encoding both run in your browser. SOAP envelopes, SAML assertions, and any tokens or PII in the payload never leave the page. Verify in DevTools → Network — no request fires when you click Encode.