Content-Disposition Header Generator

A download filename is advice, not a path to trust

Content-Disposition carries response metadata about how a recipient should handle the payload. A filename parameter can suggest the name shown in a save dialog, but it is not permission to write to that path or to trust the supplied extension.

Receiving software should discard directory components and treat the name as advisory. RFC 6266 specifically calls out path segments, confusing characters, special filesystem names, and unsafe extensions as recipient-side concerns.

filename and filename* solve different compatibility problems

The quoted filename parameter is the conservative fallback. filename* uses the extended parameter syntax now defined by RFC 8187, so a UTF-8 filename can be represented without pretending that arbitrary Unicode belongs inside a legacy quoted value.

Content-Disposition: attachment; filename="report-euro.pdf"; filename*=UTF-8''report-%E2%82%AC.pdf

When both parameters are present, modern recipients can prefer filename* while older ones still have the ASCII fallback. Spaces in the extended value are percent-encoded as %20; this is an HTTP parameter encoding, not form-style query encoding.

Attachment and inline change handling, not trust

attachment asks the recipient to save the representation instead of processing it normally. inline leaves normal handling in place and is most useful when a filename is also supplied. Browser preview still depends on the actual response media type and browser capabilities.

Neither disposition value makes active or user-supplied content safe. A server still has to choose an appropriate Content-Type, apply its own authorization and content-safety policy, and avoid serving risky content inline merely because the header syntax is valid.

Raw line breaks do not belong in a response header value

A filename copied from a form, database, or external API should never be concatenated into an HTTP field without validation. Carriage returns, line feeds, and other control characters cross the boundary from filename data into header syntax and can create response-splitting problems in poorly protected code.

With sanitization enabled, this page removes or replaces control characters and path separators before building the field. With sanitization disabled, control characters are rejected instead of being emitted.

Server snippets are only the header-setting part

The Express, Next.js, and Nginx outputs are fragments for setting response metadata. They do not open a file, authorize a download, stream a body, verify that the chosen media type matches the bytes, or decide whether the response should be cached. Those decisions belong in the surrounding application or server configuration.

References for HTTP filename handling

RFC 6266 defines Content-Disposition for HTTP responses, including disposition types, filename handling, interoperability advice, and security considerations. RFC 8187 defines the extended UTF-8 parameter encoding used by filename*.

Related Tools