Trailer HTTP Header — Reference

What it does

Trailer announces which header fields will be sent after the message body, in the trailer section of a chunked response. It's a forward declaration — the recipient knows to look for these fields after the body is fully received.

HTTP trailers allow metadata that can only be computed after the body is fully generated to be sent alongside the body — things like checksums, digital signatures, or processing metrics.

Syntax

Trailer: <header-field-name>
Trailer: <header-field-name>, <header-field-name>

Examples:

Trailer: Expires
Trailer: Checksum, Processing-Time
Trailer: X-Content-SHA256

How trailers work with chunked encoding

Trailers only work with Transfer-Encoding: chunked. The structure:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Trailer: Checksum

a\r\n
Hello Worl\r\n
1\r\n
d\r\n
0\r\n
Checksum: sha256=abc123def456...\r\n
\r\n

Trailer: Checksum declares that a Checksum field will follow the body
Body chunks are sent normally
After the terminal 0\r\n chunk, the declared trailer fields appear
Final \r\n ends the message

The recipient reads the body, then reads the trailer fields. It's as if those headers arrived at the end of the response rather than the beginning.

What trailers are useful for

Checksums and integrity verification. A server streaming a large file can compute a SHA-256 hash of the bytes as it sends them, then include the hash in a trailer. The recipient can verify the full file after receiving it — without needing to buffer the whole thing upfront to compute the hash before sending.

Digital signatures. Sign the body content after it's generated, include the signature in a trailer.

Processing metrics. Server-Timing in a trailer can report how long generating the response took, including streaming time.

Late-binding metadata. Any metadata that's only known after the full body is generated.

Headers that cannot appear in trailers

The spec explicitly prohibits certain headers from trailers because they affect how the message is processed before the body:

Transfer-Encoding — framing must be known upfront
Content-Length — must be in the initial headers
Host — routing decisions happen before body processing
Trailer itself
Authentication headers (Authorization, WWW-Authenticate)
Cache-Control, Expires (caching decisions happen early)
Content-Encoding, Content-Type, Content-Range

Sending prohibited headers in trailers is non-compliant. Clients may ignore them or treat the message as malformed.

HTTP/2 trailers

HTTP/2 supports trailers natively through HEADERS frames sent after DATA frames (with the END_STREAM flag on the final DATA frame and a subsequent HEADERS frame). This is cleaner than HTTP/1.1's chunked trailer mechanism and doesn't require Transfer-Encoding: chunked. The Trailer header still announces what trailer fields are coming.

Browser support and client handling

Browser support for HTTP trailers is limited and inconsistent. The fetch() API doesn't expose trailer fields to JavaScript as of 2026. Server-side HTTP clients (curl with --tr-encoding, custom HTTP libraries) handle trailers better than browsers.

For server-to-server communication where you control both ends, trailers are well-supported. For browser-facing responses, trailers are largely invisible to application code even if the browser correctly processes them.

Common mistakes and gotchas

Using Trailer without Transfer-Encoding: chunked. Trailers only exist in the chunked encoding format. Without chunked, there's no trailer section. Setting Trailer on a non-chunked response is meaningless.

Including forbidden headers in trailers. Sending Content-Type in a trailer is non-compliant and likely to be ignored or cause parse errors.

Not declaring trailers upfront. Sending trailer fields without declaring them in Trailer first is non-compliant. Some recipients may ignore undeclared trailers.

Real-world examples

Streaming response with integrity checksum:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Trailer: X-Content-SHA256

1000\r\n
<4096 bytes of data>\r\n
1000\r\n
<4096 bytes of data>\r\n
0\r\n
X-Content-SHA256: sha256=e3b0c44298fc1c149afbf4c8996fb924...\r\n
\r\n

Server timing trailer:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Trailer: Server-Timing

<chunks>
0\r\n
Server-Timing: db;dur=234, cache;dur=12\r\n
\r\n

FAQ

Are trailers commonly used in practice?

Rarely. The main barrier is client support — most browsers don't expose trailer values to JavaScript, making them useful only for server-to-server communication or infrastructure tooling. Checksums and Server-Timing in trailers are the most practical use cases, but even these are niche.

Is Trailer the same as a regular header that happens to come last?

No — trailers are structurally distinct from headers. They come after the body in the chunked encoding format, not in the initial header section. A header and a trailer with the same name are different things in different parts of the message.

Does HTTP/3 support trailers?

Yes — HTTP/3 (QUIC) supports trailers via HEADERS frames after DATA frames, similar to HTTP/2. The mechanism is cleaner than HTTP/1.1 chunked trailers and integrates with HTTP/3's stream model.

Fun fact

HTTP trailers solve a chicken-and-egg problem that's been part of distributed computing for decades: how do you send metadata about a stream when you don't have that metadata until the stream is complete? Email tackled it with attachments; HTTP/1.1 tackled it with trailers. Despite being in the spec since 1999, trailers never achieved broad adoption because browsers focused on request/response for web pages rather than streaming data pipelines. With the rise of gRPC (which uses HTTP/2 trailers extensively for status codes and metadata) and streaming LLM responses, trailers are finally getting more real-world use than at any point in their 25-year history.

Trailer transfer both