The Save Data API enables web applications to access information about the user's preference regarding data savings.

## Requirements and use cases This document describes an API that addresses a specific requirement: Communicate the user's preferences regarding data savings through both a JS API as well as a Client Hint. **Example use cases:** * A web application which primary purpose is to stream media could provide highly compressed media content if the user is interested in reducing their data costs. * A web application presenting the user with background videos can choose to use background images instead, based on the user's preference. ## NavigatorNetworkInformation interface The NetworkInformation interface exposes access to saveData by mixing in NetworkInformationSaveData.

  interface mixin NetworkInformationSaveData {
    [SameObject] readonly attribute boolean saveData;
  };

  NetworkInformation includes NetworkInformationSaveData;
### saveData attribute The saveData attribute, when getting, returns `true` if the user has requested a reduced data usage mode from the user agent, and `false` otherwise.

The user may enable such preference, if made available by the user agent, due to high data transfer costs, slow connection speeds, or other reasons.

#### Save-Data Request Header Field The SaveData request header is a Client Hint [[CLIENT-HINTS]]. The header's value is an `sh-list` [[STRUCTURED-HEADERS]] which contains `token`s, indicating the user agent's preference for reduced data usage.
    Save-Data = sh-list
  
This specification defines the "`on`" `token` value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode (i.e. when saveData's value is `true`), and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on. In case of multiple conflicting tokens in the list, the latest token takes precedence.
TODO: update Fetch#fetching algorithm to use `connection.saveData` as signal to append the Save-Data header.
### Handling changes to the user preference When the user's saveData preference changes, the user agent MUST run the steps to update the user preference: 1. Let new-saveData be the current saveData preference. 1. If new-saveData is not equal to the value of `connection.saveData`: 1. Using the networking task source, queue a task to perform the following: 1. Set `connection.saveData` to new-saveData. 1. Fire an event named `change` at the `NetworkInformation` object.
## Privacy Considerations This specification exposes information regarding the user's preferences, which a bit of information about the user and can be used as an active fingerprinting vector. User agents implementing this specification need to be aware of that, and take that into consideration when deciding whether to enable the feature in certain situations. For example, user agents may decide to omit or lie about the user's preference when the user is in a private browsing mode.
## IANA Considerations The following three HTTP request header fields should be added to the permanent registry of message header fields (see [[RFC3864]]), taking into account the guidelines given by HTTP/1.1 [[RFC7231]].
### `Save-Data` Request Header Field Registration * Header Field Name: Save-Data * Applicable Protocol: Hypertext Transfer Protocol (HTTP) * Status: Standard * Author/Change controller: W3C * Specification document(s): W3C TR https://www.w3.org/TR/netinfo/
## Policy-controlled features This document extends the [=policy-controlled client hints features=] with the following [=policy-controlled features=]: * `ch-save-data` which has a default allowlist of `*`
There is only one class of product that can claim conformance to this specification: a user agent.
## Acknowledgments This document reuses text from the [[HTML]] specification as permitted by the license of that specification.