JSON News Feed Format: What It Looks Like and Why It Replaced XML

Open the network tab on almost any app built in the last five years and you’ll see the same thing: JSON going back and forth, not a single angle bracket in sight. That wasn’t an accident. RSS and Atom feeds are XML at their core, and XML was the obvious choice back when feeds were designed for humans reading in a browser plugin. Once feeds started being consumed by code instead of people, the format stopped making sense.

What does a JSON news feed actually look like?

A JSON news feed represents each article as a flat object with named fields — title, author, published date, source — inside a JSON array, instead of nested XML tags. Here’s a real, trimmed response:

{
  "articles": [
    {
      "title": "Central Bank Holds Rates Steady",
      "author": "Reuters Staff",
      "published_at": "2026-07-03T14:22:00Z",
      "language": "en",
      "sentiment_label": "neutral",
      "source_link": "https://reuters.com/article/12345",
      "keywords": ["interest rates", "central bank", "economy"]
    }
  ]
}

Compare that to the equivalent chunk of an RSS/XML feed doing the same job:

<item>
  <title>Central Bank Holds Rates Steady</title>
  <author>Reuters Staff</author>
  <pubDate>Fri, 03 Jul 2026 14:22:00 GMT</pubDate>
</item>

Same information, but the XML version has no native way to express something like sentiment_label or a keywords array without inventing a custom namespace — which most RSS readers then can’t parse anyway.

Why JSON quietly took over from XML

Parse speed figures are representative benchmarks for typical article-sized payloads, not a guarantee for every implementation.

None of this makes XML wrong — RSS was built for a different job, feeding human-facing readers, and it still does that job fine. The mismatch shows up specifically when you’re building an app or pipeline that needs to filter, sort, or enrich articles programmatically, which is most of what people are doing with news data in 2026.

Parsing a JSON news feed in practice

Because JSON is a first-class citizen in virtually every language, there’s no separate parsing library to install. In Python:

import requests

response = requests.get(
    "https://api.lumenfeed.com/api/v1/articles",
    params={"q": "central bank", "sort_by": "date_desc", "per_page": 20},
    headers={"X-API-Key": "your_api_key_here"}
)
articles = response.json()["articles"]
for article in articles:
    print(article["title"], article["published_at"])

And the same call from the command line:

curl -X GET "https://api.lumenfeed.com/api/v1/articles?q=central%20bank&sort_by=date_desc&per_page=20" \
  -H "X-API-Key: your_api_key_here"

No XML parser import, no namespace handling, no dealing with CDATA blocks — the response is already the data structure you’ll work with in code.

The format was never really the hard part

Getting a JSON response is table stakes at this point — most content APIs return JSON by default. The actual work is what happens after parsing: deduplicating near-identical stories from wire syndication, filtering by language and sentiment, and keeping historical data queryable instead of just streaming the latest items. That’s less about format and more about the underlying data pipeline.

A common use case: feeding JSON news into an LLM pipeline

One place this format distinction actually matters in practice is retrieval-augmented generation. If you’re building a RAG pipeline that needs current news context, you’re not hand-parsing XML in a preprocessing script — you’re passing structured JSON objects straight into a vector store or directly into a prompt.

A typical flow looks like: query the API for a topic, take the content_excerpt and keywords fields from each returned article, embed them, and store alongside the published_at timestamp so retrieval can be filtered by recency. None of that requires touching XML at any point — the JSON structure maps directly onto whatever schema your vector database expects.

This is a big part of why JSON became the default for anything news-adjacent built after roughly 2020: the consumers of the data stopped being humans in feed readers and became scripts, and scripts don’t have a preference for XML’s verbosity when a flatter structure does the same job with less code.

LumenFeed is built around exactly this — a content aggregation API pulling from 100,000+ sources in 20+ languages, with sentiment analysis and deduplication already applied before the JSON ever reaches you. The filter_by parameter lets you narrow by language or sentiment right in the request instead of post-processing it yourself.

Getting started

The Developer plan is $4.99/mo for 10,000 requests, no card required to start, and commercial use is included on every tier. Starter and Pro scale request volume and history depth if you outgrow it, without changing the JSON structure you’re already parsing against.

For the formal JSON specification this format is built on, json.org documents the grammar in full — worth a skim if you’re implementing a custom parser rather than using a language’s built-in one.

None of this means RSS/XML is going away entirely — plenty of readers and aggregators still expect it, and it remains the right format for anything designed around a human subscribing in a feed reader. But if the thing consuming your feed is code rather than a person, JSON news feed formats are what nearly every API built in the last several years has converged on, and for good reason: less code to write, fewer edge cases to handle, and no format conversion standing between the response and the object your application actually wants to work with.

Frequently Asked Questions