HTTP Prefer Header Builder

Compose or parse an RFC 7240 Prefer request header. Toggle the standard preferences (respond-async, wait, handling, return), add custom directives with parameters, and see the matching Preference-Applied response the server should echo back. 100% in-browser.

Build

respond-async

Request async processing

wait seconds server may hold the request before returning 202

handling

(not set) lenient strict

return

(not set) minimal representation

Custom preferences

Token per RFC 7240 §2. Values that need quoting (spaces, non-token chars) are quoted automatically. Parameters follow after a semicolon.

Output

Prefer

Prefer:

Preference-Applied (expected response)

Preference-Applied:

Servers echo back only the preferences they honored. If the response omits a preference you sent, treat it as ignored (RFC 7240 §3).

curl example

curl https://api.example.com/resource

Parse an existing Prefer header

About RFC 7240

RFC 7240 introduced the Prefer header so clients can hint at optional behaviors — return me the smallest possible body, tolerate my minor errors, process this asynchronously — without demanding them. Servers pick whichever hints they can honor and echo them back in Preference-Applied. Because preferences are optional, a Prefer header must never change the meaning of a request in a way the server couldn't have inferred without it; it only tunes the response.

Common uses: OData servers accept return=minimal to skip serializing the resource on a successful PATCH; long-running batch APIs accept respond-async, wait=N to return 202 Accepted with a status URL when the work exceeds N seconds; validation-heavy APIs accept handling=strict to reject rather than repair a malformed input.