RSS Feed Builder

A feed is a file that says, in a fixed order, what is new. It lives at one address, a program fetches it now and then, and whatever was not there last time is shown to a person who asked for it. Nobody has to hand over an email address to subscribe; the reader’s own program does the asking. The RSS 2.0 specification describes its own subject in a single short sentence: a Web content syndication format.

That plainness is the whole appeal, and it is also the trap. A feed has no editor between the publisher and the reader’s software. If the file is slightly wrong, nothing sends a warning. The entries simply fail to appear, or appear twice, or carry the wrong date, and the publisher is the last to know.

Two formats and a tangled family tree

The history kept by the RSS Advisory Board begins on 15 March 1999 with RSS 0.90, published by Netscape and written by Ramanathan Guha. Version 0.91 followed that July, written by Dan Libby. In June 2000 a second 0.91 appeared from UserLand Software, written by Dave Winer, then 0.92 in December 2000 and RSS 2.0 in August 2002. In July 2003 version 2.0.1 was published by a center at Harvard Law School, and every revision since has come from the Advisory Board, whose current text, version 2.0.11, is dated 30 March 2009.

Running beside all of this is a sibling. The same history page notes that RDF Site Summary shares a common origin with Really Simple Syndication but differs by supporting the Resource Description Framework. So one family name has covered two lines of formats, which is why two files that are both called RSS may not follow the same rules.

The 2.0 specification then did something unusual: it stopped. Its roadmap says the format is, for all practical purposes, frozen, that later versions exist only to clarify, and that new work should happen in modules or in completely new syndication formats with new names. One such format arrived in December 2005 as RFC 4287, the Atom Syndication Format, published through the Internet Engineering Task Force.

The two differ less in purpose than in temper. RSS 2.0 is short, friendly and sometimes vague. Atom is longer and states its requirements with the capitalised MUST and SHOULD of a standards document. Both are XML, both list entries with titles, links and dates, and both are still read. A publisher can choose either, but has to follow the one chosen, exactly.

Dates: the same instant, written two ways

RSS borrows its date format from electronic mail. The specification says every date-time conforms to RFC 822, with one change: the year may be written with two characters or four, four preferred. RFC 822 itself, from 1982, allowed only two. RFC 1123 widened the rule seven years later and said that software should use four-digit years. RFC 5322 now treats the two-digit form as obsolete and gives the reading for it: 00 to 49 means 2000 to 2049, and 50 to 99 means 1950 to 1999.

So an RSS date with 2 or 4 digits in the year is legal, and only one of them is safe. The same goes for time zones. RFC 822 permits names such as EST and single military letters, and RFC 5322 warns that the military letters were defined wrongly in the original and should be treated as unknown. A numeric offset cannot be misread. One more rule catches hand-written feeds: if a weekday is given, RFC 822 says it must be the day the date really falls on.

Atom takes its dates from RFC 3339 and tightens them: an uppercase T between date and time, an uppercase Z when there is no numeric offset, and no white space anywhere. Stricter, and much easier to get right.

Here is one instant written both ways, which the tool on this page will reproduce. Half past seven in the morning, Universal Time, on 9 October 2026 is Fri, 09 Oct 2026 07:30:00 +0000 in RSS and 2026-10-09T07:30:00Z in Atom. Seen from a place whose clocks run five hours and forty-five minutes ahead of Universal Time, the same instant is Fri, 09 Oct 2026 13:15:00 +0545. All three name one moment. A feed that printed 13:15 and forgot the offset would be off by most of a working day.

Identifiers: how a program knows it has seen this before

A reader’s software fetches the same file again and again, so it needs a way to tell old entries from new ones. In RSS that job belongs to the guid element. The specification calls it a string that uniquely identifies the item and adds that an aggregator may choose to use it to determine whether an item is new. There are no rules for its syntax. The only promise is uniqueness, and that promise is the publisher’s to keep.

There is a quiet default attached. The optional attribute isPermaLink is true unless stated, so a reader may take the string for an address that opens in a browser. An identifier that is not one should say false.

Atom is firmer. Every feed and every entry must have exactly one id, the id must be a full IRI, and it must not change when the document is moved, republished or exported. Identifiers are compared character by character, so two addresses that lead to the same page but differ in one capital letter are two different entries. RFC 4287 goes on to say what repeated ids mean: entries that share one represent the same entry.

Two schemes make permanent identifiers without any registry. RFC 4151 defines the tag URI, built from a domain name or email address the publisher controlled on a given date plus any string they choose. RFC 9562 defines the version 4 UUID, which fills 122 bits with random data and marks the rest with a version and a variant. Either one will outlive a change of web address, which a link used as an identifier will not.

Escaping: keeping the text from breaking the container

A feed is XML before it is anything else, and XML reserves a few characters for its own structure. The ampersand and the left angle bracket may not appear as themselves in text. Five entities are predefined to stand in for them and for the right bracket and the two quotation marks. A title such as “Why 3 < 4 knots matters” must therefore be written Why 3 < 4 knots matters, or a strict parser stops at that character and reads nothing after it.

Markup inside an entry raises the stakes. A paragraph of HTML can be escaped character by character, or wrapped whole in a CDATA section, where only one sequence is still recognised: the three characters ]]> that close the section. XML forbids that sequence in ordinary text as well. Content that contains it has to be split across two sections, so that it is written as ]]]]><![CDATA[> and no single section holds the closing mark.

Some characters cannot be written at all. XML 1.0 admits tab, line feed, carriage return and everything from the space upward, apart from the surrogate range and two non-characters. A stray control character pasted from another program makes the document ill-formed, and no escape exists for it.

Then comes the question XML cannot answer: is this text, or is it HTML? The difference is not cosmetic, because the same characters mean a line break in one reading and five visible symbols in the other. Atom settles it with a type attribute that says text, html or xhtml, and gives separate rules for each. RSS 2.0 says only that entity-encoded HTML is allowed in an item description. The Advisory Board’s Best Practices Profile admits the specification lacked clarity on the point and recommends treating an item description as HTML and every other element as plain text. That is advice, and the profile says of itself that it must not be treated as definitive.

Attachments, and what no checker can see

An enclosure attaches a file to an item, which is how audio and video episodes travel in a feed. In RSS it has three required attributes, url, length, type: where the file is, how big it is in bytes, and its media type. The specification is silent on whether an item may carry more than one. The profile records that the format’s author intended a single enclosure, notes that the limit was never written down, and recommends one per item, with a length of 0 when the size cannot be known.

Namespaces are what let these formats borrow from each other. RSS 2.0 allows elements it does not define only if they belong to a namespace, and the profile uses that door to recommend one Atom element inside RSS: a link with the relation self, giving the feed’s own address. A web page, in turn, points to its feed with a link element in its head, marked as an alternate with the feed’s media type, which the HTML Standard calls feed autodiscovery.

A checker can confirm all of this on paper and still miss what matters most on the day. It cannot know whether the address in an enclosure answers, whether the file there is really the size the feed claims, or whether a link still leads anywhere, without asking the network. The tool here asks nothing. It also cannot tell how any one reading program will treat a feed that is legal but unusual, and an honest report keeps what a specification requires apart from what somebody merely advises.

What remains is modest and worth having. A feed whose dates carry four-digit years and numeric offsets, whose identifiers never change, whose text is escaped and whose attachments state their size is a feed that any conforming program can read. Nearly three decades on, that small discipline is still the price of being heard by software you have never met.