Convert an RSS or Atom XML Feed to JSON

RSS items sit under rss.channel.item. The CDATA description is unwrapped to an HTML string; pubDate stays the raw RFC-822 string — the tool does not convert it to ISO-8601.

Input:
<rss version="2.0">
  <channel>
    <item>
      <title>Hello</title>
      <link>https://ex.com/p/1</link>
      <pubDate>Mon, 01 Jun 2026 12:00:00 GMT</pubDate>
      <description><![CDATA[<p>Body</p>]]></description>
    </item>
  </channel>
</rss>

Output:
{ "rss": { "channel": { "item": {
  "title": "Hello",
  "link": "https://ex.com/p/1",
  "pubDate": "Mon, 01 Jun 2026 12:00:00 GMT",   // RAW, not ISO
  "description": "<p>Body</p>"
} } } }

Atom puts the URL in a <link href> attribute, so the converter returns an object with @href, NOT a plain string. Read entry.link['@href'] (or the right element when there are several links).

Input:
<feed xmlns="http://www.w3.org/2005/Atom">
  <entry>
    <title>Hello</title>
    <link rel="alternate" href="https://ex.com/p/1"/>
    <published>2026-06-01T12:00:00Z</published>
    <summary>Teaser</summary>
  </entry>
</feed>

Output:
{ "feed": { "entry": {
  "title": "Hello",
  "link": { "@rel": "alternate", "@href": "https://ex.com/p/1" },
  "published": "2026-06-01T12:00:00Z",
  "summary": "Teaser"
} } }

Because the tool does not unify the formats, write a tiny adapter. This is the deliberate normalisation a feed library hides — doing it yourself keeps it explicit and testable.

function normalise(item) {
  return {
    title: typeof item.title === 'object' ? item.title['#text'] : item.title,
    url:   item.link?.['@href'] ?? item.link,        // Atom vs RSS
    date:  item.published ?? item.updated ?? item.pubDate,
    body:  item['content:encoded'] ?? item.summary ?? item.description,
  };
}
// date is still a raw string here — parse with new Date(date)
// in JS or dateutil.parser.parse(date) in Python.

A feed with one item gives an object on the item key; many give an array. Aggregator code that calls .map() throws on a one-item feed. Always coalesce to an array first.

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

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

Safe Next.js usage:
const raw = data.rss?.channel?.item ?? data.feed?.entry ?? [];
const items = (Array.isArray(raw) ? raw : [raw]).map(normalise);

Podcast feeds carry the audio in an <enclosure> and image in media:thumbnail. Keep Parse attributes on so the url/length/type attributes survive as @-keys; the tool preserves them but does not move them into a 'media' object for you.

Input:
<item>
  <enclosure url="https://ex.com/ep1.mp3" length="5242880" type="audio/mpeg"/>
  <media:thumbnail url="https://ex.com/cover.jpg"/>
</item>

Output (Parse attributes ON, Strip namespaces OFF):
{ "enclosure": { "@url": "https://ex.com/ep1.mp3",
                 "@length": 5242880, "@type": "audio/mpeg" },
  "media:thumbnail": { "@url": "https://ex.com/cover.jpg" } }

RSS pubDate stays a raw RFC-822 string (Mon, 01 Jun 2026 12:00:00 GMT); Atom published/updated stay ISO-8601. The tool does no date math. Parse in your app: new Date(item.pubDate) in JS, or dateutil.parser.parse(...) in Python, before sorting.

You get the native keys: item vs entry, pubDate vs published, description vs summary, string link vs Atom link object. The converter is format-faithful, not a feed normaliser. Write a small adapter (see the cookbook) to map both into one shape.

Atom puts the URL in a href attribute, so link parses to {"@href":..,"@rel":..}. Entries with several links (alternate, enclosure, self) produce an ARRAY of link objects — pick the one with @rel=='alternate'. Code expecting a plain string URL will break.

One <item>/<entry> yields an object; multiple yield an array. .map() on the single-item object throws or iterates keys. Coalesce first: Array.isArray(x) ? x : [x]. This is the most common aggregator bug after switching to JSON.

If a description holds text interleaved with inline tags that are NOT inside CDATA (<description>See <b>this</b> link</description>), the text fragments concatenate into #text with spaces dropped (Seelink). Well-formed feeds wrap HTML in CDATA, which is unwrapped cleanly — so this only bites malformed feeds.

Many real feeds are slightly invalid (unescaped &, unclosed tags). fast-xml-parser is lenient and may return a partially-wrong object instead of throwing. If items look truncated or missing, the source feed is likely malformed — validate it before relying on the JSON.

With Strip namespaces on, media:content becomes content, which can collide with Atom's <content> element and merge into an array. Keep Strip namespaces OFF for feeds so the Media RSS, Dublin Core, and iTunes namespaces stay distinct.

RSS <guid isPermaLink="false"> parses to {"#text":..,"@isPermaLink":false} (an object) when it has attributes, or a plain string when it does not. Atom <id> is a plain string. Read item.guid?.['#text'] ?? item.guid to handle both shapes.