search

Found

info Overview

Build a Content-Disposition header per RFC 6266/5987. Pairs the ASCII filename with a UTF-8 filename* and flags non-ASCII or quote characters.

📘 How to Use

  1. Pick attachment to force a download or inline to let the browser render it
  2. Enter an ASCII filename and, if needed, a UTF-8 filename
  3. Add optional size and dates, then read the generated header

HTTP Content-Disposition Header Builder

attachment forces download; inline lets the browser render it

ASCII fallback. Older clients need this

Output as RFC 5987 percent-encoded UTF-8

Generated header

Content-Disposition: attachment; filename="report.pdf"
Copied

grid_view Related

Article

HTTP Content-Disposition Header Builder | filename and filename* in one shot

Assemble a Content-Disposition header that follows RFC 6266 and RFC 5987. The tool pairs the ASCII filename with the RFC 5987 filename* in a single output and flags non-ASCII or quote characters that typical snippet generators skip. Built for backend devs writing file-download endpoints.

💡 About this tool

If you drop a name with accents or CJK characters straight into filename="résumé.pdf", some clients show garbage in the Save dialog. The filename parameter was only meant to carry ASCII, so the fix is to also send filename* using RFC 5987 percent-encoded UTF-8. When both are present, clients that understand filename* prefer it and ignore the plain filename, which stays as a legacy fallback.

This builder writes both at once. You enter the ASCII fallback and the UTF-8 name, and it emits filename="resume.pdf"; filename*=UTF-8''r%C3%A9sum%C3%A9.pdf without you hand-encoding each byte. It also handles the optional size, creation-date, and modification-date parameters, formatting dates as HTTP-date (IMF-fixdate) so the header is spec-valid.

🧐 Frequently asked questions

Do I need both filename and filename*? For maximum compatibility, yes. Modern clients read filename* and ignore filename; older ones fall back to filename. Sending both avoids special-casing user agents.

What goes in the ASCII filename field? A name using only ASCII characters, such as resume.pdf. If you paste accented or non-Latin text there, the tool warns you and you should move that name into the UTF-8 field instead.

What is the difference between attachment and inline? attachment prompts a Save As dialog; inline asks the browser to render the content in place. Use inline for a PDF you want shown on screen, attachment to force a download.

Why does it warn about quotes or backslashes? A double quote or backslash inside a quoted filename can break parsing. The tool escapes the backslash on output but still warns, because removing those characters is the safer choice.

Are size and dates required? No. Leave them blank and they are omitted from the header. size accepts only a non-negative integer.

📚 Why two filename parameters exist

The split between filename and filename* is a backward-compatibility story. The original Content-Disposition spec only allowed ASCII in the filename token, so servers had no portable way to send Müller.pdf or a Japanese name. RFC 5987 introduced the charset'language'value form, and RFC 6266 wired it into Content-Disposition as filename*.

The convention that emerged is to send both: a stripped ASCII fallback in filename for legacy recipients, and the percent-encoded UTF-8 name in filename* for everyone else. The language tag between the two single quotes is almost always left empty, since a filename is not tied to a spoken language. Picking UTF-8 rather than ISO-8859-1 matters too, because at least one widely used implementation only ever decoded the UTF-8 form.