Atom IDs and RFC 4287: Choosing Permanent Feed and Entry Identifiers

Atom treats identity more explicitly than RSS 2.0. Every Atom feed requires an id, and every entry requires its own id. Those values are not decorative metadata. They are permanent identifiers that allow consumers to recognize a feed and its entries even when titles, links, authors, and hosting locations change.

The requirement is simple to state and easy to undermine. A generator that derives IDs from the current URL can change identity during a migration. A static build that uses the current timestamp can create new entries on every deployment. A conversion tool can replace established RSS GUIDs with fresh Atom IDs. Good Atom publishing begins by deciding what the identifiers mean, storing them, and testing that they remain stable.

Atom id is a URI, not necessarily a web address

An Atom id contains an Internationalized Resource Identifier. It must be globally unique and should never change for the represented resource. The value can be an HTTPS URL, a URN, or a tag URI. It does not have to be dereferenceable in a browser. Its purpose is identity, while Atom link elements describe locations and relationships.

The normative rules and comparison behavior are defined in RFC 4287. Publishers should follow those rules directly because small transformations that seem harmless to a developer can change the identifier as a string. Consumers should compare IDs according to the specification rather than applying arbitrary URL cleanup.

Feed identity and entry identity are separate

The feed-level ID represents the continuing publication. Entry IDs represent individual posts, releases, alerts, or other units within it. An entry’s ID must not be copied from the feed ID, and the feed ID must not be regenerated from the newest entry. The hierarchy is conceptual, not encoded by string prefixes.

A system that stores Atom data should normally key entries by both the logical feed record and the entry ID. Global uniqueness reduces collision risk, but retaining the feed relationship preserves provenance and helps when feeds are merged, mirrored, or split. The feed ID itself can be one signal when deciding whether two observed URLs expose the same publication.

HTTPS URL IDs are readable but need permanence

A canonical HTTPS URL can serve as an Atom ID when the publisher controls it and can keep it stable. For an entry, the public article URL is a common choice. For a feed, a URI specifically reserved as the identity can be clearer than the retrieval URL. The important question is whether the URI will remain unchanged when routing, domains, or content systems change.

If an entry URL changes, the Atom link rel="alternate" can point to the new page while the original ID remains. An ID is not a command to fetch the latest representation. Treating it as a permanent name allows location to evolve without creating a new entry.

Tag URIs decouple identity from hosting

A tag URI uses a domain or email authority plus a date to establish a globally unique namespace, followed by a publisher-defined component. A value can look like tag:example.org,2025:post/1842. The domain identifies an authority at the chosen date; the URI is not expected to resolve over HTTP.

This form is useful when a publisher wants readable IDs without promising that a web route will stay online forever. The dated authority should be chosen carefully, and the local component must remain unique. Like any other identifier, the result should be stored rather than reconstructed from mutable fields.

Generate once and preserve exact values

The safest implementation adds immutable fields for the feed ID and each entry ID. Assign them when the publication or entry is created. The feed renderer reads those values without changing case, encoding, or punctuation. A database constraint or application rule prevents reuse.

<feed xmlns="http://www.w3.org/2005/Atom">
  <id>tag:example.org,2025:updates</id>
  <title>Example Updates</title>
  <updated>2025-07-14T16:00:00Z</updated>
  <link rel="self" href="https://example.org/atom.xml"/>
  <entry>
    <id>tag:example.org,2025:post/1842</id>
    <title>A stable entry</title>
    <updated>2025-07-14T15:45:00Z</updated>
    <link rel="alternate" href="https://example.org/posts/stable-entry/"/>
  </entry>
</feed>

A snapshot test can record these values for representative entries and compare them during every build. The test should be insensitive to legitimate content updates but strict about IDs.

Updated timestamps do not replace identity

Atom requires an updated value for the feed and entries. That timestamp communicates modification time; it is not an identifier. A consumer can use the ID to locate a stored entry and the updated time to decide whether the representation may have changed. Generators that put a fresh timestamp on every entry during every build create unnecessary churn even if IDs remain stable.

Set an entry’s updated time when the entry’s meaningful content changes. Set the feed’s updated time according to the most recent update represented by the feed. Keep publication time in published when it is useful and known. Clear time semantics make synchronization more efficient.

Self links connect identity to retrieval

An Atom feed should publish a link rel="self" that points to the canonical URL of the feed document. The feed ID may be the same string, but it does not have to be. Keeping the concepts separate allows a permanent identity URI and a movable retrieval URL.

Resolvers can use the self link, redirect chain, feed ID, and entry overlap as independent evidence. If an old URL redirects to a new URL and both representations carry the same feed ID, the case for one continuing publication is strong. If the IDs differ, a merger should not be automatic without further evidence.

Migrating an Atom feed

Before a hosting move, export the current feed ID and all retained entry IDs. Configure the new system to import them exactly. Validate that the self link changes to the new canonical URL while IDs remain unchanged. Deploy permanent redirects from old feed URLs and update HTML autodiscovery.

A migration is not the moment to switch from URL IDs to tag URIs. That may look like an improvement, but it tells clients that every feed and entry is new. If a new scheme is required for a separate publication, use new IDs deliberately and document the relationship instead of silently rewriting history.

Converting between RSS and Atom

A converter needs an explicit identity mapping. An RSS item GUID can often be preserved as the basis of an Atom entry ID, but only if it can be represented as an IRI and the conversion remains stable. If an RSS GUID is an opaque token that is not a valid IRI, the converter can place it inside a stable URN or tag-URI namespace. The mapping must be deterministic and recorded.

Converting back from Atom to RSS requires similar care. An Atom entry ID can become an opaque RSS GUID with isPermaLink="false". Do not replace it with the current alternate link unless the publisher intentionally wants URL-based identity. The metadata guide provides a field-by-field framework for format bridges.

Consumer behavior and normalization

Consumers should store Atom IDs as published and avoid generic URL canonicalization. Removing a trailing slash, lowercasing a path, decoding reserved characters, or substituting an HTTP URL for HTTPS can collapse distinct identifiers. The URI syntax may permit several equivalent-looking representations, but the Atom comparison rules are intentionally specific.

When an ID is missing, the document is not a conforming Atom feed or entry. A tolerant application may create a local fallback to keep processing, but it should label that value as inferred and avoid presenting it as a publisher-assigned Atom ID. Fallback matching should use several signals and remain reversible.

Common Atom ID failures

• Using the current build time inside the ID.
• Copying the feed URL and changing it whenever the host changes.
• Using an entry title or slug without preserving the original value.
• Assigning the same ID to multiple entries in a batch import.
• Replacing established IDs during RSS-to-Atom conversion.
• Confusing updated timestamps or self links with identity.
• Applying URL normalization to opaque or tag-based IDs.

An implementation checklist

1. Choose a URI scheme appropriate to the publisher’s long-term control.
2. Assign one immutable feed ID and one immutable ID per entry.
3. Store IDs in content data rather than regenerating them from templates.
4. Publish a canonical self link separately from the permanent feed ID.
5. Update timestamps only when represented content changes.
6. Preserve IDs during imports, redirects, and format conversions.
7. Test uniqueness and stability in continuous integration.

Conclusion

Atom makes identity a first-class requirement. That strength pays off only when publishers treat IDs as permanent names rather than convenient copies of current URLs. Feed IDs describe the continuing publication; entry IDs describe individual resources; links describe where representations can be retrieved.

Store identifiers once, keep them exact, and let links and timestamps change for their own reasons. With that separation, Atom feeds can move between domains, systems, and formats while consumers retain a coherent history.