Content-Disposition Inspect

Parse and diagnose HTTP headers and routing signals in your browser. No input is sent to a server. Use it for first-pass observation-gap troubleshooting.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste Content-Disposition and click “Parse”. It shows disposition and parameters.

Notes (this tool)

  • Accepts a Content-Disposition: header line.

About this page

What does this tool do?

Parse Content-Disposition and list the disposition type and parameters such as filename.

Useful for troubleshooting download filenames and inline/attachment behavior.

Content-Disposition basics

  • attachment suggests download; inline suggests in-browser display.
  • filename is the save name; filename* supports encoded values.
  • Behavior depends on the combination with Content-Type.

Syntax (how to read)

Content-Disposition is formatted as “type; key=value; key=value...”. The first token is the disposition type followed by parameters like filename.

  • attachment; filename="report.pdf"
  • attachment; filename*=UTF-8''%E3%83%86%E3%82%B9%E3%83%88.pdf

filename vs filename*

If ASCII is enough, filename may work. For non-ASCII (Japanese, etc.), filename* is commonly used.

  • filename: compatibility (visible in older clients)
  • filename*: UTF-8 with percent-encoding (recommended)

Why downloads “break”

  • Content-Type mismatch causes wrong render/save behavior
  • Invalid filename* encoding causes garbling
  • Headers are stripped/modified by proxies/CDNs

Typical use cases

  • Garbled non-ASCII filenames
  • Unexpected download filename
  • Inline/attachment behavior differs by browser

Common parameters

  • attachment; filename="report.pdf"
  • attachment; filename*=UTF-8''%E3%83%86%E3%82%B9%E3%83%88.pdf
  • inline; filename="image.png"

Common pitfalls

  • Misunderstanding filename vs filename* precedence
  • Encoding mismatch causes garbling
  • Incorrect Content-Type breaks inline display

Debugging workflow (recommended)

  • Check Content-Disposition and Content-Type in DevTools
  • Parse filename/filename* and compare with expectations
  • Use Response Headers Parser to review all response headers
  • Content-Type Inspect
  • Response Headers Parser
  • URL Encode/Decode (helps decode filename*)

What this tool does

  • Extract disposition type
  • Show filename/filename*
  • Normalize parameters

Operational notes

  • Intermediaries may rewrite headers. Compare captures from equivalent points.
  • Confirm final decisions with server logs and configuration such as trusted proxy and routing.

Referenced specs

  • RFC 6266 (Content-Disposition)
  • RFC 5987 (extended parameters)

FAQ

Which wins: filename or filename*?

filename* typically takes precedence when supported by the client.

Why does inline still download?

Depending on Content-Type and browser support, inline may still download.

Best practice for non-ASCII filenames?

A common approach is using an ASCII fallback in filename and the true UTF-8 name in filename*.

References

  1. RFC 6266
  2. RFC 5987
  3. MDN: Content-Disposition
  4. MDN: Content-Type

These links are generated from site_map rules in recommended diagnostic order.

  1. Retry-After Inspect — Parse Retry-After and inspect retry wait behavior
  2. Response Headers Parser — Parse response headers into structured data
  3. Server-Timing Inspect — Parse Server-Timing and inspect latency metrics
  4. Content-Type Inspect — Parse Content-Type and inspect MIME/charset