JSON to XML in DataWeave and MuleSoft — Prototype, Then Build

DataWeave is MuleSoft's transformation language. output application/xml handles JSON-to-XML declaratively, with full control over attributes, namespaces, and repeated elements. For production flows, DataWeave is the right tool. For previewing the target XML shape before you write the script, a browser converter gets you there in seconds. This guide covers the combined workflow.

The DataWeave output application/xml Basics

Minimal DataWeave 2.0 script:

%dw 2.0
output application/xml
---
{
  customer: {
    id: payload.customerId,
    name: payload.name
  }
}

Output XML:

<?xml version='1.0' encoding='UTF-8'?>
<customer>
  <id>C-3391</id>
  <name>Ana</name>
</customer>

DataWeave handles the JSON input via payload, you define the XML shape explicitly. Unlike our browser tool, DataWeave requires you to write the mapping — but also gives you full control over the shape.

Preview Before Writing the Script

1. Grab a sample JSON payload.
2. Paste into our browser converter, set the root element.
3. See what the default element-per-key shape looks like.
4. Open Anypoint Studio, write DataWeave that produces the same shape.
5. Adjust DataWeave for attributes, namespaces, wrapping elements your consumer needs.

The browser preview is your reference — "here's what straight conversion looks like, now I need to tweak X and Y." Without it, you're writing DataWeave blind.

Sell Custom Apparel — We Handle Printing & Free Shipping

Attributes in DataWeave — the @() Syntax

DataWeave expresses XML attributes with @(key: value):

%dw 2.0
output application/xml
---
{
  customer @(id: payload.id): {
    name: payload.name
  }
}

Produces <customer id="C-3391"><name>Ana</name></customer>. Our browser converter doesn't do attributes — it outputs elements only. When your target needs attributes, plan to add the @() wrappers in DataWeave yourself.

See our attributes guide for the general explanation of why element-only output is a safe default.

Namespaces in DataWeave

DataWeave declares namespaces at the top of the script:

%dw 2.0
output application/xml
ns ns0 http://example.com/schema
---
{
  ns0#customer: {
    ns0#name: payload.name
  }
}

Browser converter output has no namespaces — same story as attributes. Plan to add namespace declarations in DataWeave.

If you're targeting a SOAP service, namespaces are usually required. DataWeave's declarative syntax makes this cleaner than post-processing our browser tool's output with XSLT.

When Browser Conversion Is Actually Enough

You don't always need DataWeave. Our browser tool is enough when:

• You're debugging a single payload, not building a flow.
• The target XML is element-only (no attributes, no namespaces).
• You're writing docs or a test fixture for a REST-to-SOAP bridge.
• Mule 4 runtime isn't available on the machine you're on.

For production IFlows and Anypoint deploys, use DataWeave. The browser tool is for the quick preview, not a replacement.

Frequently Asked Questions

Does DataWeave produce the same output as my browser tool?

Only if you write minimal DataWeave that mirrors key-to-element mapping. DataWeave's strength is explicit control — you can shape output with attributes, namespaces, and wrapping elements that a browser converter can't match automatically.

Can I skip DataWeave by using a browser tool inside Mule 4?

No — Mule runtime doesn't call external URLs for transformations. Use DataWeave in the Transform Message component or, for edge cases, a custom Java component.

What about DataWeave 1.0 (Mule 3)?

Same concept, different syntax. output application/xml works the same way; attribute syntax is slightly different (@name vs @(name:)). Our browser tool's output is equally useful as a preview reference.

How do I handle JSON arrays in DataWeave XML output?

Map over the array and produce repeated elements with the same key name: `{ items: payload.items map ((item) -> { item: item }) }`. Our browser tool shows you the target shape; DataWeave lets you express it declaratively.