The Cookie-Preference HTTP Header Field

4.1. Syntax

Cookie-Preference is a Structured Header Field [RFC9651] whose value MUST be a single Item (Section 3.3 of [RFC9651]).¶

Its ABNF [RFC5234] production is:¶

Cookie-Preference = sf-item

The bare-item MUST be an sf-token (Section 3.3.4 of [RFC9651]) whose value is one of the (case-insensitive) values in Table 1.¶

Additional token values MAY be defined in extensions or future registrations in an IANA registry.¶

The Item MAY include Parameters (Section 3.1.2 of [RFC9651]) for extensibility. Parameters follow the bare-item, separated by semicolons with optional whitespace. Unrecognized parameters MUST be ignored by recipients.¶

The following are non-normative examples:¶

Cookie-Preference: essential

Cookie-Preference: all; level="high"

Cookie-Preference: ask; granularity="category"

(Note: Parameters like "level" or "granularity" are illustrative only; their semantics would need to be defined if registered or used in practice.)¶

4.2. Semantics

When present, the "Cookie-Preference" field signals the user's overall preference for cookie acceptance on requests to the origin.¶

User agents SHOULD send this header on requests where cookie-setting behavior is relevant (e.g., navigation requests or sub-resource loads that may involve cookies). User agents MAY apply different values on a per-origin basis (e.g., based on user-configured site-specific settings) or send a global default.¶

Origin servers SHOULD inspect the parsed value of Cookie-Preference (per the parsing algorithm in Section 4 of [RFC9651]) and adjust their cookie-setting behavior accordingly (refer to Section 4.3).¶

The preference is advisory: servers are not required to honor it, and user agents MUST NOT rely on servers complying (e.g., they SHOULD still apply client-side cookie blocking if configured). If parsing fails at the server or the value is unrecognized, the entire field MUST be ignored (per [RFC9651] error handling).¶

4.3. Server Behavior

Origin servers that understand the "Cookie-Preference" header field SHOULD take it into account when deciding whether to include Set-Cookie headers in responses, but they are not required to do so. The preference is advisory only; servers MAY ignore it entirely if honoring it would break site functionality, violate other policies, or would be problematic for any other reason.¶

When honoring the signaled preference:¶

• For "essential", servers SHOULD limit Set-Cookie headers to those cookies classified as strictly necessary (per definitions in relevant privacy regulations or equivalent guidelines).¶
• For "none", servers SHOULD refrain from setting any cookies.¶
• For "ask", servers SHOULD restrict themselves to essential cookies and use other mechanisms to solicit more specific user consent.¶
• For "all", servers MAY set cookies without restriction.¶

Once a cookie has been successfully set (i.e., the Set-Cookie header was sent and processed by the user agent), this document does not require or define any mechanism for revoking or modifying it based on a subsequent Cookie-Preference value. Cookie lifecycle and management remain governed by [RFC6265] (or its successor) and user agent policies.¶

This document does not require or define any mechanism for revoking or modifying cookies set as a result of a previous Cookie-Preference header. Cookie lifecycle and management remain governed by [RFC6265] (or its successor) and user agent policies.¶

Servers SHOULD NOT infer strong privacy commitments solely from this header (e.g., it does not substitute for valid legal consent under applicable regulations).¶

6.1. Fingerprinting and Linkability

Sending the "Cookie-Preference" header field reveals information about the user's privacy settings or attitudes toward cookies. Since the set of possible values is small and discrete ("all", "essential", "none", "ask"), and many user agents may send the same default value, the header alone provides limited entropy. However, when combined with other request information (e.g., User-Agent, Accept-Language, or other preference headers), it can contribute to fingerprinting the user agent or linking requests across origins/sessions. User agents SHOULD mitigate this by:¶

• Applying the same value globally unless the user explicitly configures per-origin exceptions.¶
• Omitting the header on requests where it is not relevant (e.g., cross-origin sub-resource requests that do not involve cookie-setting).¶
• Randomizing or varying non-essential headers when privacy is a concern (though this is outside the scope of this document).¶

Servers MUST NOT rely on this header as a reliable indicator of user identity or linkability across requests without additional context.¶

6.2. Spoofing and Non-Compliance

The header is sent by the user agent and can be trivially spoofed by clients, extensions, or proxies. Servers SHOULD treat the preference as advisory only and MUST NOT depend on it for security-critical decisions (e.g., assuming "essential" means no tracking cookies are needed for compliance with law).¶

Conversely, user agents MUST NOT assume servers will honor the preference; they SHOULD continue to apply client-side cookie blocking or restrictions as configured by the user.¶

6.3. Interaction with Legal Consent Requirements

This document defines a technical signaling mechanism and does not define, modify, or substitute for legal requirements related to obtaining valid consent for cookies or similar state management technologies.¶

Servers remain fully responsible for complying with applicable laws regarding cookie consent, notice, and choice. In particular:¶

• The presence of a "Cookie-Preference" header (or any specific value within it) does not, by itself, constitute legally valid consent under frameworks that require explicit, informed, and affirmative user action.¶
• The absence of the header or reception of an unknown value does not imply or grant permission to set cookies.¶

However, when a user agent sends "Cookie-Preference: all" (or equivalent future values indicating broad acceptance), servers MAY interpret this as the user's expressed preference to accept cookies without further prompting, especially in jurisdictions or contexts where opt-out signals are sufficient, or where the user agent has already obtained and recorded consent on behalf of the user. Servers SHOULD honor such signals where feasible by omitting consent dialogs and setting cookies consistent with the indicated preference, thereby improving user experience while still respecting applicable legal obligations.¶

Likewise, when a user agent sends "Cookie-Preference: essential", servers MAY interpret this as the user's expressed preference to accept only cookies that are essential for site operation. If additional cookies are desired, the site MAY prompt the user to accept additional cookies.¶

This mechanism is intended to reduce reliance on repetitive per-site consent dialogs by providing a standardized, upfront expression of user intent. User agents and servers are encouraged to align their implementations with evolving best practices and regulatory guidance regarding machine-readable preference signals.¶

6.4. General Guidance

Implementers should consult [RFC6973] for broader privacy considerations in protocol design, and Section 17 of [RFC9110] for general HTTP security guidance. In particular, any future extensions that add parameters or new values to "Cookie-Preference" SHOULD include their own privacy analysis.¶