SOAP & WSDL XML Formatter — Format and Inspect XML Online

Working with SOAP usually means working with a lot of XML. A response that looks perfectly readable in a formatted editor can become surprisingly difficult to understand when it arrives as one long line in a log file.

That's where an XML formatter can save some time.

With the XML Formatter & Converter, you can format SOAP messages and WSDL files, validate the XML, inspect namespaces, test XPath expressions, compare two XML documents, and convert XML into other formats. Everything runs in the browser, so there is no account to create just to look at a request or response.

Formatting a SOAP Request

A SOAP message normally has an envelope, and depending on the service, it may also contain a header and a body.

For example, a request might look something like this:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
              xmlns:ord="http://example.com/orders">
  <soap:Header>
    <ord:RequestId>ABC-123</ord:RequestId>
  </soap:Header>
  <soap:Body>
    <ord:GetOrderRequest>
      <ord:OrderId>10045</ord:OrderId>
    </ord:GetOrderRequest>
  </soap:Body>
</soap:Envelope>

This is manageable when it is properly indented. The same document becomes much harder to work with when a logging system puts everything onto a single line.

To format a SOAP message:

1. Open XML Formatter & Converter.
2. Paste the SOAP request or response into the editor.
3. Select Format.
4. Check the envelope, header, and body in the formatted output.
5. Use the namespace or XPath tools if you need to inspect specific elements.

If the formatter cannot parse the document, start with XML validation. A missing closing tag, invalid character, or broken attribute can prevent the rest of the document from being processed.

SOAP Header and Body: What's the Difference?

When debugging SOAP, it helps to separate the header from the body.

The header is commonly used for information such as authentication, request identifiers, timestamps, routing information, or other metadata required by the service.

The body normally contains the actual operation being requested.

For example:

<soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:auth="http://example.com/auth"
    xmlns:ord="http://example.com/orders">

  <soap:Header>
    <auth:Token>...</auth:Token>
    <auth:RequestId>ABC-123</auth:RequestId>
  </soap:Header>

  <soap:Body>
    <ord:GetOrderRequest>
      <ord:OrderId>10045</ord:OrderId>
    </ord:GetOrderRequest>
  </soap:Body>

</soap:Envelope>

If a request is failing, looking at these two sections separately can make troubleshooting much easier. An authentication problem is usually a different issue from an incorrectly structured operation in the body.

Finding Values with XPath

Once the XML is formatted, XPath is useful when you need to find a particular value without manually searching through a large document.

Using the example above, you could use an XPath expression similar to:

/soap:Envelope/soap:Body/ord:GetOrderRequest/ord:OrderId

That would point to the OrderId element.

You can try expressions like this in the XML XPath Tester.

One thing to watch for is namespaces. An XPath expression can look completely correct and still return nothing if the namespace mapping is wrong.

Why SOAP Namespaces Cause So Many Problems

Namespaces are probably one of the first things I would check when a SOAP request looks correct but an XPath query or integration still does not behave as expected.

Consider these two elements:

<ord:GetOrderRequest>

and

<order:GetOrderRequest>

The prefixes are different, but that alone does not tell you whether the elements are actually different. What matters is the namespace URI associated with the prefix.

For example:

xmlns:ord="http://example.com/orders"

The prefix ord is simply a shorthand for that namespace URI.

That's why changing a prefix does not necessarily change the underlying XML meaning, while changing the namespace URI can.

The namespace inventory in the formatter can be useful when you're dealing with a document containing several namespaces such as SOAP, XML Schema, WSDL, and application-specific namespaces.

If an XPath query unexpectedly returns no results, check:

• Does the XML parse successfully?
• Is the XPath using the correct namespace?
• Does the element name actually exist in the document?
• Are you looking in the SOAP header or the body?

Those checks usually narrow the problem down quickly.

Formatting a WSDL File

WSDL is XML too, but it serves a different purpose.

A SOAP request tells you what is being sent. A WSDL generally describes the service contract: available operations, messages, data types, bindings, ports, and services.

A real WSDL can therefore become quite large.

When it has been minified or generated by another system, finding a particular definition can be frustrating. Formatting it first makes the document much easier to navigate.

Open the XML Formatter & Converter, paste the WSDL, and format it. From there, the tree view can help you move between sections such as:

• definitions
• types
• message
• portType
• binding
• service

This is particularly useful when you receive a WSDL from a third-party provider and need to understand what changed between versions.

Comparing Two WSDL Versions

A WSDL update does not always mean that the service has completely changed. Sometimes the difference is a new type, a renamed element, a changed message part, or a modification to a binding.

If you have the previous and current WSDL files, comparing them before updating generated client code is a good idea.

Use XML Compare to see what actually changed instead of comparing two large files manually.

Whitespace changes are much less interesting than changes to the actual service contract. A structural comparison can make those changes easier to spot.

Minifying SOAP XML

Pretty-printed XML is great when you're debugging. It isn't always what you want to store or send.

Once you have finished inspecting the document, you may want to create a compact version for a test fixture, configuration value, or another system that expects a single-line XML string.

That's where Minify comes in.

You can also remove comments or normalize attribute ordering when preparing XML for comparison.

I would normally keep the formatted version while debugging and only minify the final copy. It is much easier to troubleshoot readable XML than a single line containing several thousand characters.

You can also use the XML Minifier when you only need to reduce whitespace.

Converting SOAP XML to JSON

Sometimes you need to look at a SOAP response next to a REST API response. Converting the XML to JSON can make that comparison easier.

The XML to JSON converter can help with that, but the result should be treated as a representation of the XML rather than a perfect replacement for it.

Namespaces, attributes, repeated elements, and mixed content don't always have an obvious JSON equivalent. A conversion that looks reasonable may still need adjustment before it is used in application code.

For that reason, I would use the conversion mainly for inspection or data extraction, and keep the original XML as the source of truth.

If you're working with the resulting JSON, you can inspect it with the JSON Formatter & Converter.

Useful Tools When Working with Integration Data

SOAP debugging often involves more than just XML formatting.

You may receive escaped XML:

<soap:Envelope>...</soap:Envelope>

or a Base64-encoded value containing another payload.

In those situations, the utility tools can be useful for decoding the value before putting it back into the XML editor.

The XML Formatter & Converter includes tools for:

• XML escape and unescape
• Base64 encode and decode
• URL encode and decode

These are especially handy when XML is embedded inside another request or transport format.

Working with Sensitive SOAP Traces

Be careful when pasting production SOAP traffic into any online tool.

SOAP requests can contain authentication information, customer identifiers, internal URLs, order numbers, and other data that should not be shared publicly.

The formatter processes the XML in your browser for its main editing and inspection features, so you can work with local files without creating an account. If you use an action such as importing a URL, that is different: the browser needs to request the remote resource, and whether it works depends on the target server and its CORS configuration.

Even when processing happens locally, I recommend replacing passwords, tokens, customer information, and other sensitive values before sharing a formatted request with someone else.

A Simple SOAP Troubleshooting Workflow

When a SOAP request is failing, you don't necessarily need to inspect every part of the document at once.

A practical workflow is:

1. Format the XML

First make the request readable.

2. Validate it

Make sure the XML itself is well-formed. If it isn't, fix that before investigating the SOAP operation.

3. Check the namespace declarations

Look at the namespace URIs used by the envelope and application-specific elements.

4. Look at the header

Check authentication, request IDs, timestamps, and other metadata required by the service.

5. Look at the body

Confirm that the expected operation and parameters are present.

6. Test XPath

Use XPath to confirm that important values such as an order ID or request ID can actually be found.

7. Compare with a known-good request

If you have a request that works, compare it with the failing one. This is often much faster than guessing what the server expects.

Start with a Sample Before Using a Production Trace

If you're new to SOAP or WSDL, start with a small example rather than immediately pasting a huge production trace.

Load one of the built-in samples, format it, open the namespace information, and try a simple XPath expression. Then make a small change and compare the original with the modified version.

Once those steps make sense, move on to your real request.

That approach is also useful when you're learning a new SOAP integration. You can understand the structure without having to deal with a 5,000-line WSDL or a production response containing sensitive information.

When a SOAP/WSDL Formatter Is Useful

A formatter is particularly useful when:

• A SOAP request or response appears on one long line.
• You need to inspect a SOAP header separately from its body.
• An XPath expression isn't returning the expected value.
• You're trying to understand unfamiliar namespace declarations.
• A WSDL file is difficult to navigate.
• A service provider has published a new WSDL.
• You want to compare a working request with a failing one.
• You need to quickly inspect or convert XML without installing a desktop application.

For a broader introduction to the editor, see the XML Formatter guide.

You can also try the XML XPath Tester, XML Validator, XML Compare, or XML to JSON Converter depending on what you're working on.

Related XML Tools

If you're working with SOAP or WSDL, these tools may also be useful:

• XML Formatter & Converter
• XML Validator
• XML XPath Tester
• XML Compare
• XML to JSON Converter
• XML to YAML/CSV Converter