A signed exchange (SXG) is a delivery mechanism that makes it possible to authenticate the origin of a resource independently of how it was delivered. This article provides an overview of SXGs.
SXGs are supported by Chromium-based browsers (starting with versions: Chrome 73, Edge 79, and Opera 64).
Signed Exchanges (SXGs) allow a site to cryptographically sign a request/response pair (an "HTTP exchange") in a way that makes it possible for the browser to verify the origin and integrity of the content independently of how the content was distributed. As a result, the browser can display the URL of the origin site in the address bar, rather than the URL of the server that delivered the content. Separating content attribution from content distribution advances a variety of use cases such as privacy-preserving prefetching, offline internet experiences, and serving content from third-party caches.
The SXG format
An SXG is encapsulated in a binary-encoded file that has two primary components: an HTTP exchange and a signature. The HTTP exchange consists of a request URL, content negotiation information, and an HTTP response.
Here's an example of a decoded SXG file:
format version: 1b3
Expires: Mon, 24 Aug 2020 16:08:24 GMT
Content-Type: text/html; charset=UTF-8
Date: Mon, 17 Aug 2020 16:08:24 GMT
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=
The exchange has a valid signature.
payload [1256 bytes]:
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
expires parameter in the signature indicates a SXG's expiration date. A
SXG may be valid for at most 7 days. If the expiration date of an SXG is more
than 7 days in the future, the browser will reject it. Find more information on
the signature header in the Signed HTTP Exchanges
SXGs are a part of the broader Web Packaging spec proposal family. In addition to SXGs, the other major component of the Web Packaging spec is Web Bundles ("bundled HTTP exchanges"). Web Bundles are a collection of HTTP resources and the metadata necessary to interpret the bundle.
The relationship between SXGs and Web Bundles is a common point of confusion. SXGs and Web Bundles are two distinct technologies that don't depend on each other—Web Bundles can be used with both signed and unsigned exchanges. The common goal advanced by both SXGs and Web Bundles is the creation of a "web packaging" format that allows sites to be shared in their entirety for offline consumption.
SXGs are the first part of the Web Packaging spec that Chromium-based browsers will implement.
Initially, the primary use case of SXGs will likely be as a delivery mechanism
for a page's main document. For this use case, a SXG could be referenced using
<a> tags, as well as the
<link rel="prefetch" as="document" href="https://example.com/sxg">
Although a SXG could theoretically be referenced using a
tag, this is not the recommended approach to loading
SXG. Tooling support for the SXG subresource loading is less mature, and
therefore this use case is not covered in this document - however, you can read
more about it in Signed Exchange subresource
Like other resources, a SXG can be loaded by entering its URL in the browser's address bar.
Content negotiation is a mechanism for serving different representations of the same resource at the same URL depending on the capabilities and preferences of a client—for example, serving the gzip version of a resource to some clients but the Brotli version to others. Content negotiation makes it possible to serve both SXG and non-SXG representations of the same content depending on a browser's capabilities.
Web browsers use the
request header to communicate the MIME
they support. If a browser supports SXGs, the MIME type
application/signed-exchange will automatically be included in this list of
For example, this is the
Accept header sent by Chrome 84:
application/signed-exchange;v=b3;q=0.9 portion of this string informs the
web server that Chrome supports SXGs—specifically, version
b3. The last part
q=0.9 indicates the
q-value expresses a browser's relative preference for a particular format
using a decimal scale from
1 representing the highest
priority. When a
q-value is not supplied for a format,
1 is the implied
Servers should serve SXGs when the
Accept header indicates that the
application/signed-exchange is greater than or equal to the
The following regular expression can be used to match the
Accept header of
requests that should be served as SXG:
Note that the subexpression
(,|$) matches headers where the
q-value for SXG
has been omitted; this omission implies a
1 for SXG. Although an
Accept header could theoretically contain the substring
browsers don't explicitly list a format's
q-value when it has the default
Debugging SXGs with Chrome DevTools
Signed Exchanges can be identified by looking for
signed-exchange in the
Type column of the Network panel in Chrome DevTools.
The Preview tab provides more information about the contents of a SXG.
This section discusses the tooling options and technical requirements of SXGs.
At a high level, implementing SXGs consists of generating the SXG corresponding to a given URL and then serving that SXG to users. To generate a SXG you will need a certificate that can sign SXGs.
Certificates associate an entity with a public key. Signing a SXG with a certificate allows the content to be associated with the entity.
Production use of SXGs requires a certificate that supports the
CanSignHttpExchanges extension. Per
certificates with this extension must have a validity period no longer than 90
days and require that the requesting domain have a DNS CAA
Web Packager is an open-source, Go-based tool that is the de facto tooling for generating ("packaging") signed exchanges. You can use it to manually create SXGs, or as a server that automatically creates and serves SXGs. Web Packager is currently in alpha.
Web Packager CLI
The Web Packager CLI generates a SXG corresponding to a given URL.
Once the SXG file has been generated, upload it to your server and serve it with
application/signed-exchange;v=b3 MIME type.
Web Packager Server
This is the server's default interface:
In the above example, an instance of
webpkgserver running on
would return the contents of
https://example.com as an SXG.
the default name of the
webpkgserver endpoint. Use the
to customize the name of this endpoint, as well as many other settings.
webpkgserver should not use a public endpoint. Instead, the
frontend web server should forward SXG requests to
contain more information on running
webpkgserver behind a frontend edge
NGINX SXG Module
The NGINX SXG module generates and serves SXGs. Sites that already use NGINX should consider using this module over Web Packager Server.
The NGINX SXG module only works with
CanSignHttpExchangescertificates. Setup instructions can be found here.
gen-signedexchangeis a tool provided by the webpackage specification as a reference implementation of generating SXGs. Due to its limited feature set,
gen-signedexchangeis useful for trying out SXGs, but impractical for larger-scale and production use.