Website Review
What is ALL-about-RSS?
ALL-about-RSS is a curated directory of RSS-related resources: readers, tools, services, specifications, validators, communities and tutorials. It lives at ALL-about-RSS and is organized as a browsable list rather than a blog or a single product.
Its scope is broader than "reader apps." The page groups entries into sections such as:
- What is RSS — introductory images, videos and explainer pages in English and Chinese.
- Web Feed Specifications or Extensions — specs, converters and comparison tools.
- RSS Feed Validator — tools for checking that a feed is well formed.
- RSS Readers — apps, WeChat mini apps, hosted and self-hosted readers, email-based readers, terminal/programmable readers, and services built on GitHub, Notion or Obsidian.
- Players and server/backend tools — including smartwatch apps and other clients.
- Connections between readers, tools and services — shown through an interactive node chart.
- Free servers and bridges — RSSHub, Tiny Tiny RSS, FreshRSS, RSS-Bridge and Full-Text RSS.
- Bots and integrations — Telegram, QQ, WeChat, Mastodon, Matrix and microblogging platforms.
A few practical details make the list easier to use. Entries carry icons indicating open-source software, free web services, platform availability (Windows, macOS, Linux, iOS/iPadOS, Android), browser extensions, Firefox add-ons, podcast or video format, and AI integration. Items discussed in the associated Telegram channel or on Twitter are marked with linked superscripts. The page states that it is not an "Awesome list" and that any well-functioning, well-maintained service or tool can be included, in no particular order.
Who it is for: someone who wants to find an RSS reader for a specific platform, compare hosted versus self-hosted options, validate a feed, or discover bridges and bots that bring RSS into other apps. It is also useful for developers looking for specifications and converters.
A practical next step: decide your constraint first — platform, self-hosting willingness, or need for full-text extraction — then jump to the matching section rather than reading the whole page. For example, if you want to follow sites that do not offer feeds, start with the RSS-Bridge or RSSHub entries; if you want a reader you can run yourself, start with the self-hosted section.
How do I choose between hosted, self-hosted, and email-based RSS readers?
Choose based on where you want the reading list to live and who keeps it running.
- Hosted readers are run by a company or project. You sign in, add feeds, and read in a browser or app. They are the fastest start, sync across devices, and usually work well on phones. The trade-off is that the service decides what features exist, whether the reader survives, and how your data is handled.
- Self-hosted readers run on a server or computer you control. You install and update them, and you can often connect any client. They give you the most control over your feeds and data, but you take on setup, backups, and maintenance. This is the right choice if you already run a small server or want a reader that will not disappear when a company shuts down.
- Email-based readers deliver new items to your inbox. They fit people who already live in email and want no separate app. The trade-off is inbox clutter, weaker feed organization, and less control over how articles are displayed or searched.
A practical comparison:
| Option | Best for | Main cost |
|---|---|---|
| Hosted | Beginners, phone-first readers, quick setup | Less control; dependent on the service |
| Self-hosted | Tinkerers, privacy-minded users, long-term archives | Setup and maintenance time |
| Email-based | Inbox-centric users, low-volume feeds | Clutter; limited reading and sorting tools |
A useful next step is to write down three things: how many feeds you follow, which devices you read on, and whether you are willing to update software. If the answers are "many feeds, several devices, no maintenance," start hosted. If they are "I want to own the data and I can run a server," go self-hosted. If they are "I mostly read on one device and want everything in one inbox," try email delivery.
For a broad directory of readers, tools, and tutorials, including hosted, self-hosted, and email-system categories, see ALL-about-RSS. For a widely used self-hosted option, see FreshRSS, and for a hosted feed service that many readers build on, see Feedly.
Which RSS feed validators and specification tools should I use to check my feed?
For day-to-day feed checking, start with a dedicated validator rather than building your own tests. On ALL-about-RSS, the validator sits alongside the feed specifications and extension references, which is a useful pairing: validate first, then read the spec when a warning doesn't make sense.
A practical workflow
- Validate the raw feed URL, not a rendered page.
- Fix structural errors (malformed XML, wrong dates, missing required elements) before worrying about warnings.
- Check which spec your feed claims — plain RSS 2.0, Atom, or an extension like Podcasting 2.0 or JSON Feed.
- Re-validate after each change, then test in two or three readers, since readers differ in how strictly they parse.
What each kind of tool is for
- Validators catch XML errors, encoding problems, and element ordering. They are the fastest way to find why a feed won't load at all.
- Specification references tell you whether a tag is required, optional, or an extension — useful when a validator complains about something you intended.
- Specification converters help if you're moving between formats, for example syndicating an Atom feed where a consumer expects RSS.
- Comparison tools help when you need to see how two formats or two versions of the same feed differ.
The list's own annotation system is worth noting: entries are marked for open source, free web services, platform availability, and AI integration. For a validator, prioritise open source or a long-running free service, since a validator that disappears takes your debugging workflow with it.
Choosing between them
| Your situation | What to reach for |
|---|---|
| Feed won't load in any reader | A strict validator that reports line-level XML errors |
| Feed loads but shows wrong dates or titles | Spec reference for the date and text element rules |
| Publishing a podcast feed | Validator plus the relevant extension spec |
| Migrating RSS to Atom or JSON Feed | A specification converter, then re-validate |
| Feed works in one reader, not another | Validate, then compare against the spec's optional elements |
A concrete scenario: you run a small blog and a listener says your feed is empty in their app. Validate the feed URL directly — you may find an unescaped ampersand in a post title, which breaks parsing for stricter readers while a lenient one silently skips the item. Fix the character, re-validate, then confirm in two readers.
As a next step, open the validator on the list, run your feed, and keep the specification section open in a second tab for anything the report flags.
How can I use RSSHub, RSS-Bridge, or Full-Text RSS to generate feeds for sites without RSS?
RSSHub, RSS-Bridge, and Full-Text RSS all solve the same basic problem in different ways: they turn a page or service that lacks a native feed into something your reader can subscribe to. The right pick depends on whether you need a broad catalog of ready-made routes, a self-hosted converter you can extend, or a way to pull full article text into an existing feed.
What each tool is for
- RSSHub is a route-based feed generator. You subscribe to a URL pattern for a supported site or service, and RSSHub returns a feed. It is the fastest option when your target is already covered, and it is the one to try first if you don't want to write code.
- RSS-Bridge is a self-hosted set of "bridges," each targeting a site or page pattern. It is useful when you want to run the converter yourself, avoid depending on a public instance, or handle sites that RSSHub doesn't cover.
- Full-Text RSS is not primarily a site-to-feed generator. It takes an existing feed or article URL and extracts the full article content, so it pairs well with a partial feed from RSSHub, RSS-Bridge, or the site itself.
A practical decision path
- Check for an existing route or bridge first. If RSSHub or RSS-Bridge already supports the site, use that instead of building anything.
- Match the tool to the gap. Missing feed entirely → RSSHub or RSS-Bridge. Feed exists but only shows excerpts → Full-Text RSS.
- Decide who hosts it. Public instances are convenient but can be rate-limited or blocked. Self-hosting gives you control and privacy, at the cost of setup and maintenance.
- Test the output in your reader. Confirm the feed validates, updates at a sane interval, and includes the fields you actually read (title, date, author, content).
Example scenario
You follow a site that publishes news but offers no feed. You find an RSSHub route for it and subscribe. The feed works, but each item is only a headline and a teaser. You then run those item URLs through Full-Text RSS so your reader shows the whole article. If RSSHub has no route, you check RSS-Bridge for a matching bridge, and if neither exists, you self-host one of them and write a small custom rule.
Trade-offs to weigh
| Tool | Best for | Main cost |
|---|---|---|
| RSSHub | Ready-made coverage of many sites | Reliance on public instances or your own deployment |
| RSS-Bridge | Self-hosted, extensible conversion | More manual configuration per site |
| Full-Text RSS | Completing partial feeds | Adds a processing step; extraction can miss complex layouts |
Next step
Start with the site you care about, search the RSSHub and RSS-Bridge documentation for a matching route or bridge, and only then consider writing your own. The ALL-about-RSS list is a useful index for finding readers, validators, and related tools once your feed is working.
What RSS bots and integrations are available for Telegram, WeChat, Mastodon, and Matrix?
For chat and social platforms, rss.tips lists a dedicated "RSS bots" section covering Telegram, QQ, WeChat, Mastodon, and Matrix, plus a separate note on a full-article extractor bot. That makes it a useful index if you want feeds delivered into a messenger or microblogging timeline rather than a standalone reader.
What the list covers
- Telegram — a "Telegram RSS bots" grouping, i.e. bots that push feed items into Telegram chats or channels.
- WeChat — both a "WeChat Mini Apps" reader category and a WeChat entry under RSS bots, so you can either read feeds inside WeChat or have them forwarded to it.
- Mastodon — listed under RSS bots, alongside a broader "Microblogging Platform" heading.
- Matrix — also listed under RSS bots.
- QQ — a "酷Q Plugin" entry, relevant mainly to Chinese-language users on that platform.
The page also notes a bot tied to RSS屋, described as a full-article extractor service — useful when a feed only carries summaries and you want the complete text in the chat message.
How to choose
The list itself is explicit that it is not curated as an "Awesome list": anything that works well and is actively maintained can appear, and entries are in no particular order. So treat it as a starting inventory, not a ranking.
A practical filter, based on the icons the page defines:
| Your situation | What to look for |
|---|---|
| You want no setup or hosting | A hosted bot or web service (the page marks these separately from self-hosted tools) |
| You want control over data | Open-source entries that link to their repository |
| You need full article text, not just headlines | The full-article extractor bot |
| You want feeds inside a chat app you already use | The Telegram, WeChat, Matrix or Mastodon bot entries |
Next step: open the "RSS bots" section, pick the platform you actually use, then check whether the bot is open-source (repo link) or a hosted service — that distinction usually decides whether you can keep it running long-term. If you would rather read feeds in a dedicated app instead of a chat, the same page's "RSS Readers" categories (apps, hosted, self-hosted, terminal-based) are the better place to start.
How can I self-host an RSS reader using GitHub, Notion, or Obsidian?
Self-hosting an RSS reader through GitHub, Notion, or Obsidian means using those platforms as the storage or automation layer rather than running a traditional feed server. ALL-about-RSS groups these as distinct categories — "RSS services powered by utilizing GitHub," "…utilizing Notion," and "…utilizing Obsidian" — alongside separate categories for hosted and self-hosted readers, so the site treats them as a real, if unconventional, option.
What each platform actually gives you
| Platform | Best for | Main trade-off |
|---|---|---|
| GitHub | Scheduled fetching via Actions; feeds stored as files in a repo | Not a reading interface by itself — you still need a viewer or static site |
| Notion | Reading and annotating inside a database you already use | Depends on Notion's API and your integration staying alive |
| Obsidian | Keeping feeds as notes next to your own writing | Requires the app open or a sync setup; weak on high-volume feeds |
GitHub suits people who want the fetching to be free, versioned, and inspectable. A workflow runs on a schedule, pulls feeds, and commits the results to a repository. You then read them through a static page, a generated digest, or by opening the files directly. The appeal is durability and full control; the cost is that you are maintaining a pipeline, and reading is a second problem you have to solve.
Notion works well if Notion is already your information home. A service writes new items into a database, and you read, tag, and comment there like any other content. You get a good reading and search experience without building a UI, but you are trusting a third-party integration with your feeds, and export is messier than plain files.
Obsidian fits note-takers who want feeds to land as Markdown notes alongside their own thinking. The value is proximity: you can link an article to a project note immediately. The friction is volume — a busy feed list can flood a vault — and mobile reading depends on your sync setup.
A practical next step
Decide by where you already read, not by which platform sounds most technical. If you want a conventional reader with folders, unread counts, and apps on every device, a self-hosted reader such as FreshRSS or Miniflux is the more direct route, and ALL-about-RSS lists both under self-hosted readers. Reserve the GitHub/Notion/Obsidian approaches for when you specifically want feeds to live inside a repo, a database, or a vault. To compare the alternatives in one place, start at ALL-about-RSS.
User reviews (0)