Convert a WordPress WXR Export to JSON

The post body lives in content:encoded wrapped in CDATA; the converter unwraps it to a clean HTML string. Custom fields come through as wp:postmeta pairs.

Input (WXR item):
<item>
  <title>Launch Day</title>
  <wp:post_id>42</wp:post_id>
  <wp:status>publish</wp:status>
  <content:encoded><![CDATA[<p>We shipped!</p>]]></content:encoded>
  <wp:postmeta>
    <wp:meta_key>_thumbnail_id</wp:meta_key>
    <wp:meta_value><![CDATA[88]]></wp:meta_value>
  </wp:postmeta>
</item>

Output (Strip namespaces OFF, Coerce types ON):
{
  "title": "Launch Day",
  "wp:post_id": 42,
  "wp:status": "publish",
  "content:encoded": "<p>We shipped!</p>",
  "wp:postmeta": { "wp:meta_key": "_thumbnail_id",
                   "wp:meta_value": 88 }
}

Stripping namespaces turns BOTH content:encoded and excerpt:encoded into the same encoded key. fast-xml-parser merges same-named siblings into an array — so you lose which is the body and which is the excerpt. Leave Strip namespaces OFF for WXR.

Input:
<item>
  <excerpt:encoded><![CDATA[Short teaser]]></excerpt:encoded>
  <content:encoded><![CDATA[<p>Full body</p>]]></content:encoded>
</item>

Strip namespaces ON (BAD):
{ "encoded": [ "Short teaser", "<p>Full body</p>" ] }
  -> which is which? order-dependent and fragile

Strip namespaces OFF (GOOD):
{ "excerpt:encoded": "Short teaser",
  "content:encoded": "<p>Full body</p>" }

The tool imports everything — drafts, revisions, attachments. Use json-path-extractor to keep only published posts before you write the import loop, so you do not push revisions into the new CMS.

After conversion you have rss.channel.item = [ ..mixed.. ]

/tool/json-path-extractor expression:
  $.rss.channel.item[?(@.wp:post_type=='post')]
then chain:
  $.[?(@.wp:status=='publish')]

=> only published posts of type 'post' remain;
revisions (wp:post_type=='revision') and attachments
(wp:post_type=='attachment') are excluded.

Export one post and item is an object; export several and it is an array. Your import loop must handle both, or always test against a multi-post export.

One post:
{ "rss": { "channel": { "item": { "title": "Only post" } } } }

Many posts:
{ "rss": { "channel": { "item": [ {..}, {..} ] } } }

Node import loop (safe):
const items = [].concat(data.rss.channel.item ?? []);
for (const post of items) { await cms.create(map(post)); }

Each post can carry several wp:postmeta pairs. Flatten them into a lookup so your importer can address fields by name, then map to the destination schema.

Converted item.wp:postmeta:
[ { "wp:meta_key": "seo_title",  "wp:meta_value": "Launch" },
  { "wp:meta_key": "reading_time", "wp:meta_value": 3 } ]

Reshape in your importer:
const meta = Object.fromEntries(
  [].concat(item['wp:postmeta'] ?? [])
    .map(m => [m['wp:meta_key'], m['wp:meta_value']]));
// meta.seo_title === 'Launch', meta.reading_time === 3
Use /tool/json-key-filter first to drop meta you do not need.

Both fields strip to encoded. Because they are siblings, fast-xml-parser merges them into an encoded array, and you can no longer tell body from excerpt reliably. For WXR, leave Strip namespaces OFF and keep the prefixed keys, then rename in your importer if needed.

WXR includes every wp:post_type — post, page, revision, attachment, nav_menu_item. The tool converts them all. Filter after conversion with json-path-extractor ([?(@.wp:status=='publish')]) so you do not import revisions or menu items into the new CMS.

Export with one post and rss.channel.item is an object; with many it is an array. An import loop that assumes an array will misbehave on a one-post export. Normalise with [].concat(item ?? []) or test against a multi-post export.

Attachment items carry the file URL in <guid> / <wp:attachment_url>, but WXR never embeds binary image data. After conversion you must fetch each URL and re-upload to your new media store. The tool surfaces the URLs; it cannot download the images.

content:encoded is a raw HTML string (Gutenberg block comments included, e.g. <!-- wp:paragraph -->). The tool delivers it verbatim. Targets needing Portable Text (Sanity) or Rich Text (Contentful) must run the HTML through an HTML-to-rich-text converter at import — that is outside this tool's scope.

WXR uses <category domain="category"> for categories and <category domain="post_tag"> for tags — same element name, distinguished by the domain attribute. Keep Parse attributes on so you get @domain, then split categories from tags in your importer by inspecting @domain.

A post with several wp:postmeta entries gives an array; a post with exactly one gives a single object. Normalise with [].concat(item['wp:postmeta'] ?? []) before mapping, or some posts will silently lose their meta in the import.

Post bodies in content:encoded make WXR files large fast. The free tier caps files at 2 MB. A blog with a few hundred long posts will exceed that — use Pro (100 MB per file), or export by post type / date range to produce smaller WXR files before converting.