HTTP download metadata
Content-Disposition Header Parser and Builder
Parse or build Content-Disposition headers for inline and attachment responses. Inspect quoted filenames and UTF-8 filename parameters.
Input is processed locally in this browser
Content-Disposition parser workspace
Disposition
attachment
Effective filename
résumé 2026.pdf
| Parameter | Decoded value | Encoding |
|---|---|---|
| filename | report.pdf | HTTP quoted/token value |
| filename* | résumé 2026.pdf | utf-8 |
Understand the filename a browser may present
Parse or build Content-Disposition headers for inline and attachment responses. Inspect quoted filenames and UTF-8 filename parameters. A valid header does not guarantee a browser's download presentation. Navigation context, sandboxing, MIME type, and platform filename rules also matter. Treat an untrusted filename as data rather than a filesystem path, and verify the complete response in its destination context.
How to use the Content-Disposition parser
- Choose Parse and paste a field value from a response, including or omitting the field name.
- Review the disposition, parameters, decoded values, effective filename, and safety warnings.
- Choose Generate, select
attachmentorinline, and enter the intended filename. - Copy the generated value into server code, then test the real response in each supported browser.
Why send both filename and filename*?
filename supplies an ASCII-compatible fallback. filename*=UTF-8''... preserves names such as résumé.pdf. When both are valid, modern recipients should prefer the extended value.
A filename is not authorization
Never concatenate a received filename with a storage directory. Remove directory components, reject control characters, generate a server-side storage name, and set the media type independently.
Standards and parser boundaries
Field grammar and precedence guidance come from RFC 6266. International parameter encoding follows RFC 8187. The decoder supports UTF-8 and ISO-8859-1, the character sets recipients are expected to understand for this use.
User-agent download behavior also depends on navigation context, sandboxing, same-origin rules, the HTML download attribute, MIME sniffing protections, and platform filename rules. This tool validates one field value; it cannot guarantee browser presentation.
Frequently asked questions
Why does filename* take precedence over filename?
RFC 6266 recommends that recipients choose filename* when both parameters are present because filename* can carry an explicitly encoded international filename. The plain filename remains a compatibility fallback for older clients.
Does a parsed filename make a download path safe?
No. Content-Disposition provides advisory presentation metadata, not a trusted filesystem path. Strip path separators and control characters, choose your own destination directory, and apply the platform rules of the receiving system.
Can one Content-Disposition field contain several filenames?
Duplicate parameter names make the field invalid under RFC 6266. The parser preserves the first parsed parameter and reports duplicates so the sending application can be corrected.
Is the header or filename uploaded while parsing?
No. Parsing, percent decoding, fallback generation, and warning checks all run locally in the active browser tab; Toolk analytics do not receive the field value.
Related tools
Last updated: September 15, 2026