The W3C Feed Validator is a long-established, free, generic tool: point it at a feed URL and it checks the XML is well-formed and conforms to the general RSS or Atom syndication-format specifications. Based on its own public description, it is a solid, established first stop for "is this even valid XML in a syndication format" — the same job for RSS/Atom feeds that a markup validator does for HTML.
Podcast Feed Validator does a narrower, podcast-specific job. The iTunes and
Podcast namespace elements Apple Podcasts actually requires — itunes:category,
itunes:explicit, itunes:image, per-episode itunes:episodeType
— are a separate namespace layered on top of general RSS, defined after and outside the base
spec a general validator checks against. A feed can be perfectly well-formed, spec-conformant
RSS and still be missing every element Apple's Podcasts Connect requires for submission. This
tool checks those elements specifically, plus two podcast-app-specific failure modes a general
validator has no reason to look for: a pubDate not in the RFC 822 format podcast
apps expect, and a duplicate guid across episodes — the documented cause of an
episode disappearing or reappearing as new in a subscriber's app.
| Question | Where to answer it |
|---|---|
| My feed URL won't parse at all, or I'm not sure it's well-formed XML. | W3C Feed Validator — general well-formedness is its job. |
| My feed is valid RSS but Apple Podcasts rejected the submission, or an episode isn't showing up. | Podcast Feed Validator — checks the iTunes/Podcast-namespace elements a general validator doesn't know about. |
| An old episode reappeared as new, or a recent one vanished. | Podcast Feed Validator's duplicate-guid check — a general RSS validator has no reason to flag two valid, well-formed items sharing a guid value. |
| I want this checked automatically on every publish, with nothing sent to a third party. | Podcast Feed Validator's CLI — node check.mjs <feed-url> runs from your own machine and exits non-zero on a finding, wireable into any CI or publish script as an ordinary step. |
Neither tool replaces the other. Run the W3C Feed Validator first if you're not sure the XML itself is sound; run this one for the podcast-specific requirements that actually decide whether Apple Podcasts, Spotify, and other podcast apps accept and correctly display your show.
Different jobs, and many podcasters need both at different times. The W3C Feed Validator, based on its own public description, checks that a feed is well-formed, spec-conformant XML against the general RSS/Atom syndication formats — it is the right first stop for a feed that won't parse at all. Podcast Feed Validator instead checks the iTunes/Podcast-namespace elements and podcast-app-specific rules the W3C tool has no knowledge of: itunes:category against Apple's own taxonomy, itunes:explicit's current boolean format, cover artwork, and the guid/pubDate bugs that cause an episode to disappear or reappear in a subscriber's app.
Based on its own public description, no — it validates against the general RSS 2.0 and Atom syndication-format specifications, which predate and do not include the iTunes/Podcast namespace Apple defines separately for podcast-specific metadata (category, explicit rating, episode type, artwork). A feed can pass general RSS well-formedness and still be missing every element Apple's Podcasts Connect actually requires.
No. This site is not affiliated with, endorsed by, or sponsored by the World Wide Web Consortium (W3C) or its Feed Validator. It is named here only to describe what that tool does and how it differs from this one, based on its own public description.