I like JSON Feed

Recently, I implemented JSON Feed support for my static site generator, Lifer. My impression is that, in 2026, JSON Feed is still not widely used, while people continue to rediscover RSS¹ thanks to the indie web resurgence and an appetite for re-decentralization. Bluesky supports RSS; Mastodon supports RSS; Substack supports RSS; even Reddit supports RSS²—but none of them support JSON Feed.

It makes sense for JSON Feed to be less popular than RSS: it’s not nearly as old or entrenched; it was created at a time, pre-Twitter implosion, in which feed reading had been subsumed by Twitter; and it doesn’t offer much new or different over RSS, so why bother. That said, after looking at my implementations of RSS 2.0 and Atom versus my implementation of JSON Feed, I found lots to like about JSON Feed.

The rationale provided by the authors of the spec isn’t written in a persuasive way:

We—Manton Reece and Brent Simmons—have noticed that JSON has become the developers’ choice for APIs, and that developers will often go out of their way to avoid XML. JSON is simpler to read and write, and it’s less prone to bugs.

Let me reframe this to be more compelling.

JSON is better than XML at storing HTML as data

In an Atom feed, you must encode HTML nodes inside of the <content> XML node so that they don’t look like the next XML node in the feed. This means, if you’re publishing HTML in your feeds, that the XML is even less human-readable than usual. See this excerpt from my blog’s feed:

  <entry>
    <content>
      &lt;p&gt;Here’s another blog post vouching for writing Ruby blocks
      using the semantic rule. Sometimes called “the Weirich rule”
      because of &lt;a href=&quot;
      https://en.wikipedia.org/wiki/Jim_Weirich&quot;&gt;
      Jim Weirich&lt;/a&gt;’s “Braces vs. Do/End” article&lt;
      sup id=&quot;fnref:weirich&quot;&gt;&lt; a href=&quot;#fn:weirich&quot;
      class=&quot;footnote&quot; rel=&quot;footnote&quot;
      role=&quot;doc-noteref&quot;&gt;1&lt;/a&gt;&lt;/sup&gt; and an issue
      he filed against &lt;
      a href=&quot;https://github.com/rubocop/ruby-style-guide/issues/162&quot;&gt;&lt;code&gt;rubocop/ruby-style-guide&lt;/code&gt;&lt;/a&gt;.
      The rule unambiguously answers the question posed by Weirich: “When
      should you use &lt;code&gt;{}&lt;/code&gt; for blocks and when
      should you use &lt;code&gt;do&lt;/code&gt;/&lt;code&gt;end&lt;/code&gt;?”
      His answer:&lt;/p&gt; <!--…-->
    </content>

I know you’re thinking that these feeds aren’t meant to be read by humans in the raw, so who cares. As a developer, though, wouldn’t you rather deal with simpler raw data? Here’s the same excerpt in JSON Feed (unminified):

"content_html":
  "<p>Here’s another blog post vouching for writing Ruby blocks using
  the semantic\nrule. Sometimes called “the Weirich rule” because
  of <a href=\"https://en.wikipedia.org/wiki/Jim_Weirich\">Jim
  Weirich</a>’s\n“Braces vs. Do/End”
  article<sup id=\"fnref:weirich\"><a
  href=\"#fn:weirich\" class=\"footnote\" rel=\"footnote\"
  role=\"doc-noteref\">1</a></sup> and an issue he filed against\n<a
  href=\"https://github.com/rubocop/ruby-style-guide/issues/162\"><code>rubocop/ruby-style-guide</code></a>.
  The rule unambiguously answers the\nquestion posed by Weirich:
  “When should you use <code>{}</code> for blocks and when\nshould
  you use <code>do</code>/<code>end</code>?” His answer:</p> ..."

JSON is more accessible than XML

JavaScript is one of the most widely-used programming languages in the world, and JavaScript Object Notation is a first-class feature of the language. In a JavaScript context, it’s easy to both generate and parse valid JSON.

Since parsing JSON takes no effort, even client-side in a web browser, I feel there are opportunities for us to go beyond feed reading and aggregation with JSON Feeds. The cost of parsing is so low, and the specified structure is simple. Desktop web browsers can even autoformat JSON to be nicely human readable³.

New programmers and non-programmers can make sense of JSON, and JSON parsing tools, pretty quickly. Feel free to pair this with my “HTML doesn’t need to be escaped in JSON Feed” argument above. RSS is just more abstract to read and slightly more error-prone to write. Given this, I think JSON Feed has the accessibility edge over RSS.

The standard exchange format is JSON

Many popular programming languages besides JavaScript also have first-class support for JSON. For example, I implemented JSON Feed generation support in Ruby using Ruby’s standard JSON library. Writing the implementation in Ruby felt no different than doing it in JavaScript.

The reason you’ll find JSON libraries built into so many languages is because it’s normal for API services respond to clients in JSON these days. In my experience, XML-based APIs have been eclipsed by JSON-based ones. Even as far back as 2011, a blog post by Dmitriy Samovskiy, “JSON vs. XML in API,” indicates that developers were realizing that designing JSON-based APIs resulted in a less complex system:

There is no easy and universal way how to represent nested hashes and arrays using XML (if there is, I hope to hear from you about it—I need stable libraries that can convert arrays and hashes to XML and back that could interop among each other for all major programming languages). Of course it’s possible and not terribly difficult, but it’s something that one must do.

Contrast this situation with JSON—you don’t need to worry about this, it’s already taken care of for you. The only limitation of JSON that we faced was that JSON doesn’t like integers as hash keys, it wants you to convert them to strings or use an array instead of a hash.

I would guess most of the software developers I’ve met and worked with, my age or younger, have never had to consume an API that responds in XML. (Even more of them may not know what SOAP is.)

If JSON is the standard exchange format, it makes sense that websites would benefit from providing content in that format so that content can be read… standardly. The longevity and resilience of RSS has made it the standard for website feeds, but we have watched the rest of the Web move on to JSON for good enough reasons. I’d say “why not JSON Feed?” since it already exists and is well specified.

Software developers are good at working with JSON

Implementing JSON Feed was a breeze. I compared my implementations of Atom, RSS, and JSON Feed generation side by side. They’re all shaped the same way, and there are only a few more lines of code to required to handle some RSS specification things. What made it a breeze was the simplicity of the JSON library API I was using: the public interface is minimal; the method names match my mental model for working with all kinds of (non-JSON Feed) JSON data.

My comparison revealed to me that the standard Ruby library for RSS is pretty bespoke and hasn’t been used by nearly as many people over the years. It’s not a bad library, but there’s so much friction that simply doesn’t exist when slinging JSON. It’s no contest.

Anyway, this website now has a JSON Feed if you’d like to subscribe to my posts that way.