Content-Disposition for downloads and inline content
The HTTP Content-Disposition response header suggests how a browser should present a response. attachment normally opens a download prompt. inline asks the browser to display the representation normally when it supports the media type. A filename is advisory: the receiving application must still sanitize it before writing to disk.
International filenames need special handling. The plain filename parameter is useful as an ASCII compatibility fallback, while filename* carries a UTF-8 value using percent encoding. Sending both gives modern clients the intended name without abandoning older clients.
Example with a Unicode filename
For Q4 résumé.pdf, the generator produces output similar to:
Content-Disposition: attachment; filename="Q4 resume.pdf"; filename*=UTF-8''Q4%20r%C3%A9sum%C3%A9.pdf
The ASCII fallback is deliberately conservative. Quotes, backslashes, control characters, and path separators need careful treatment because filenames come from an untrusted header context. This tool rejects carriage returns and line feeds to prevent header injection.
Parsing existing headers
The parser shows the disposition type, fallback filename, and decoded extended filename. It is intended for debugging a single header field. It does not reproduce every recovery behavior used by every browser, and duplicate parameters are reported rather than guessed away.
The header does not determine the response media type. Send an accurate Content-Type separately, and use X-Content-Type-Options: nosniff when appropriate. For inline resources, also consider a restrictive Content Security Policy. To encode a small resource directly into markup, use the Data URI Generator.
Security and privacy
Treat any received filename as a suggestion, strip directory components, prevent overwriting sensitive files, and apply operating-system-specific filename rules. A valid header does not make an unsafe file safe to open.
All generation and parsing happens locally in the browser. MiniUtil does not receive filenames or header values.
The header field and its filename guidance are specified by RFC 6266. Extended parameter encoding is defined by RFC 8187.