You’re reading the English version of this content since no translation exists yet for this locale. Help us translate this article!
Content-Dispositionresponse header is a header indicating if the content is expected to be displayed inline in the browser, that is, as a Web page or as part of a Web page, or as an attachment, that is downloaded and saved locally.
multipart/form-data body, the HTTP
Content-Disposition general header is a header that can be used on the subpart of a multipart body to give information about the field it applies to. The subpart is delimited by the boundary defined in the
Content-Type header. Used on the body itself,
Content-Disposition has no effect.
Content-Disposition header is defined in the larger context of MIME messages for e-mail, but only a subset of the possible parameters apply to HTTP forms and
POST requests. Only the value
form-data, as well as the optional directive
filename, can be used in the HTTP context.
|Header type||Response header (for the main body)
General header (for a subpart of a multipart body)
|Forbidden header name||no|
As a response header for the main body
The first parameter in the HTTP context is either
inline (default value, indicating it can be displayed inside the Web page, or as the Web page) or
attachment (indicating it should be downloaded; most browsers presenting a 'Save as' dialog, prefilled with the value of the
filename parameters if present).
Content-Disposition: inline Content-Disposition: attachment Content-Disposition: attachment; filename="filename.jpg"
As a header for a multipart body
The first parameter in the HTTP context is always
form-data. Additional parameters are case-insensitive and have arguments that use quoted-string syntax after the
'=' sign. Multiple parameters are separated by a semi-colon (
Content-Disposition: form-data Content-Disposition: form-data; name="fieldName" Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
- Is followed by a string containing the name of the HTML field in the form that the content of this subpart refers to. When dealing with multiple files in the same field (for example, the
multipleattribute of an
<input type="file">element), there can be several subparts with the same name.
namewith a value of
'_charset_'indicates that the part is not an HTML field, but the default charset to use for parts without explicit charset information.
- Is followed by a string containing the original name of the file transmitted. The filename is always optional and must not be used blindly by the application: path information should be stripped, and conversion to the server file system rules should be done. This parameter provides mostly indicative information. When used in combination with
Content-Disposition: attachment, it is used as the default filename for an eventual "Save As" dialog presented to the user.
The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in RFC 5987. When both "filename" and "filename*" are present in a single header field value, "filename*" is preferred over "filename" when both are understood.
A response triggering the "Save As" dialog:
200 OK Content-Type: text/html; charset=utf-8 Content-Disposition: attachment; filename="cool.html" Content-Length: 21 <HTML>Save me!</HTML>
This simple HTML file will be saved as a regular download rather than displayed in the browser. Most browsers will propose to save it under the
cool.html filename (by default).
An example of an HTML form posted using the
multipart/form-data format that makes use of the
POST /test.html HTTP/1.1 Host: example.org Content-Type: multipart/form-data;boundary="boundary" --boundary Content-Disposition: form-data; name="field1" value1 --boundary Content-Disposition: form-data; name="field2"; filename="example.txt" value2 --boundary--
|RFC 7578||Returning Values from Forms: multipart/form-data|
|RFC 6266||Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)|
|RFC 2183||Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field|
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
|Chrome Full support Yes||Edge Full support Yes||Firefox Full support Yes||IE Full support Yes||Opera Full support Yes||Safari Full support Yes||WebView Android Full support Yes||Chrome Android Full support Yes||Firefox Android Full support Yes||Opera Android Full support Yes||Safari iOS Full support Yes||Samsung Internet Android Full support Yes|
- Full support
- Full support
- Firefox 5 handles the
Content-DispositionHTTP response header more effectively if both the
filename*parameters are provided; it looks through all provided names, using the
filename*parameter if one is available, even if a
filenameparameter is included first. Previously, the first matching parameter would be used, thereby preventing a more appropriate name from being used. See bug 588781.