Cache-Groups

The HTTP Cache-Groups response header assigns a response to one or more named cache groups, enabling coordinated invalidation of related resources.

Table of Contents

Usage

Invalidating cached content often affects multiple related resources. A POST request updating a user profile might invalidate the profile page, dashboard, and settings page. Cache-Groups solves this by associating each response with named groups. When the server triggers invalidation via Cache-Group-Invalidation, caches supporting the mechanism mark cached responses sharing the specified group names as stale. Group-based invalidation is optional for caches.

The header accepts one or more group identifiers as Structured Field strings. Group names are arbitrary server-defined strings representing logical relationships between resources. A response might belong to multiple groups.

This header works alongside Cache-Group-Invalidation to provide grouped cache management independent of URL patterns or Cache-Control directives.

Values

The Cache-Groups header accepts a structured field list of strings representing group identifiers. Each identifier represents a logical grouping defined by the server.

Cache-Groups: "user-123"
Cache-Groups: "user-123", "profile-pages"

Group names are case-sensitive and scoped to the origin. Servers choose names based on data dependencies, feature boundaries, or administrative convenience.

Example

A user profile page belongs to two groups: one scoped to the user identifier and one representing all profile-related pages.

Cache-Groups: "user-456", "profiles"

When a POST request updates the user's profile, the server includes Cache-Group-Invalidation in the response. Caches invalidate all stored responses associated with the specified group.

Cache-Group-Invalidation: "user-456"

This invalidates the profile page, dashboard, and any other resource tagged with the user-456 group, while preserving cached responses belonging to unrelated groups.

A content management system might use groups representing content types and publication status. An article response belongs to both the articles group and the published group.

Cache-Groups: "articles", "published"

Publishing a new article triggers invalidation for the published group, refreshing article lists and feeds without affecting draft content or unrelated resources.

Scope and adoption

The mechanism operates inside a single cache and a single origin, by design. Group membership requires the same string, compared case-sensitively character by character, on responses from the same origin, and nothing synchronizes groups across a cache hierarchy or between origins. Implementations supporting the field handle at least 32 groups of 32 characters each.

Every behavior is optional. A cache is permitted to invalidate group members together and equally permitted to ignore the field, and the specification points at targeted cache-control fields as the way a future profile makes the signal binding for a particular CDN.

No shipping implementation is known. The field pair is registered and published, with the vendor tagging mechanisms, Cache-Tag and Surrogate-Key, carrying production purge traffic in the meantime. The standards-track pair models the same relationships with registered fields, and the difference in maturity is the whole story today.

Shared hosting carries the named risk: tenants sharing an origin share the group namespace, so one tenant groups or invalidates another's responses unless the host filters the fields.

See also

Last updated: August 17, 2026