Content-Disposition Parser & Generator
Inspect ordered filename parameters or generate an ASCII fallback with UTF-8 filename*
Local text inspection, limited to 1 MiB. Filenames are suggestions, not safe paths or browser guarantees. Input is not saved.
Parsed or generated output will appear here.
About this tool
Content-Disposition Parser and Generator inspects a single HTTP field value, optionally prefixed with Content-Disposition:. The parser preserves parameter order and spelling, handles semicolons inside quoted strings, and applies HTTP quoted-pair escaping. Parameter names are case-insensitive; repeating any name makes the field invalid and filename selection ambiguous rather than silently choosing a winner. A valid filename* takes priority over filename, including an explicitly empty extended value. UTF-8 decoding rejects malformed byte sequences. Legacy ISO-8859-1 decoding maps bytes directly to their Latin1 code points; it is not Windows-1252. Other charsets and unescaped non-ASCII extended values are unsupported. Generation accepts inline or attachment and emits an escaped ASCII fallback plus optional UTF-8 filename* following RFC 8187. The result shows the requested name, actual fallback and suggested name separately, so disabling filename* cannot imply that an international name survived unchanged. Input controls and unpaired surrogates are rejected; parsed path separators and decoded controls receive advisories. This is not filename sanitization, a multipart/form-data parser, MIME validation or a guarantee of browser behavior. Editing input or settings clears the previous result. Processing stays local with no saved input, and text is limited to 1 MiB and 2000 lines.
Scenario Recipes
Verify what a multilingual download header actually carries
Goal: Compare an international requested filename with its emitted fallback.
- Parse attachment; filename="fallback.txt"; filename*=ISO-8859-1''caf%E9.txt and verify the suggestion café.txt.
- Switch to Generate, enter 报告.pdf and disable filename*. Confirm the actual header and suggestion contain __.pdf.
- Enable filename*, generate again, and compare the UTF-8 parameter with the separate ASCII fallback before testing your supported browsers.
Result: Header encoding and fallback choice are visible; filesystem rules and browser behavior still need separate checks.
Frequently Asked Questions
Which filename wins when both parameters exist?
A valid filename* is the suggested value, even when it is empty. filename remains visible as a fallback candidate. An invalid extended value makes the parse invalid.
What happens to duplicate filename parameters?
Case-insensitive duplicates make the field invalid. All parameters remain listed, and suggestedFilename is null because selection is ambiguous.
Does ISO-8859-1 use the same decoder as UTF-8?
No. Latin1 maps each byte directly, so %E9 becomes é and %80 is U+0080, not the euro sign. UTF-8 uses strict byte decoding.
What remains if I omit filename* when generating?
Only the ASCII fallback is emitted. Accents are decomposed where possible and other non-ASCII characters become underscores; inspect the displayed actual fallback.
Are semicolons and backslashes inside quotes literal?
A semicolon inside a complete quoted string stays in the value. An HTTP quoted-pair consumes its backslash; for example a backslash before b yields b, not a literal backslash.
Can I save directly to the suggested filename?
Apply the receiving application’s path, reserved-name, extension and collision rules first. The parser supplies a suggestion, not a safe path or a browser outcome. Inputs are processed locally without storage.
Keep browsing