W3C Trace Context: traceparent and tracestate

Last verified on Nov 8, 2026.

W3C Trace Context is the standard for passing a trace from one service to the next in HTTP headers. It defines two headers, traceparent and tracestate, so that services using different tracing tools can still join one distributed trace. The current text is a W3C Recommendation dated 23 November 2021, and it is the default propagation format in OpenTelemetry.

The traceparent Header

traceparent has four fields separated by hyphens, all lowercase hex:

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

A receiver must ignore a traceparent whose IDs are invalid, for example all zeros or non-hex characters. Vendors should send the header name in lowercase, but must accept any case on input.

Trace Flags and the Sampled Bit

sampled is the least significant bit. When set, the caller may have recorded trace data. The flags are recommendations, not commands: the spec gives three reasons, trust and abuse, bugs in the caller, and different load between caller and callee, which might force the callee to downsample. Because it is a bit field, test it with a mask. 09 has the sampled bit set, and 00 does not.

The tracestate Header

tracestate carries optional, vendor-specific data beside traceparent. It is a comma-separated list of key=value entries, with at most 32 members. Vendors should propagate at least 512 characters of the combined header. The spec's own example shows two vendors cooperating:

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
tracestate: congo=t61rcWkgMzE

traceparent: 00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01
tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE

The second service keeps the trace ID, replaces the parent ID with its own span ID, and adds its entry at the left of tracestate. A service that receives traceparent must send it on to outgoing requests, and it may mutate the value first. Every tracing tool must set traceparent correctly even if it relies on tracestate for its own data.

Parsing and Generating Values

This validator accepts only version 00, which is all most services see. Higher versions may carry extra fields, and the spec has separate rules for them. It ran correctly against the example header above, an all-zero trace ID (rejected), uppercase hex (rejected), and flags 09 (sampled):

import re

TRACEPARENT = re.compile(r'^([0-9a-f]{2})-([0-9a-f]{32})-([0-9a-f]{16})-([0-9a-f]{2})$')

def parse(header):
    m = TRACEPARENT.match(header)
    if not m:
        return None
    version, trace_id, parent_id, flags = m.groups()
    if version != '00' or set(trace_id) == {'0'} or set(parent_id) == {'0'}:
        return None
    return {'trace_id': trace_id, 'parent_id': parent_id, 'sampled': bool(int(flags, 16) & 1)}

To test a service by hand, generate random IDs and send them:

curl -H "traceparent: 00-$(openssl rand -hex 16)-$(openssl rand -hex 8)-01" https://example.com/health

The spec says randomly generated trace IDs are preferred.

W3C Trace Context vs Other Headers

• Baggage. W3C Baggage is a separate specification, independent of Trace Context, for application-defined key-value pairs in a baggage header. It carries your data. Trace Context carries what tracing needs.
• Platform headers. AWS load balancers add X-Amzn-Trace-Id, which has a different format. Keep both, and log both. See correlation ID.
• Logs. OpenTelemetry's log data model stores the same flags in TraceFlags, so the sampled bit follows the trace into log records.

Trace Context in Sazabi

Sazabi, an AI-native observability and security platform, correlates spans and logs by trace context, per its traces documentation. Setup for exporting is in OpenTelemetry traces. The OpenTelemetry integration page links the other setup guides.