Why does HttpUtility.UrlEncode(HttpUtility.UrlDecode(“%20”)) return + instead of %20?

I’m having a problem with a file download where the download is replacing all the spaces with underscores.

Basically I’m getting a problem here:

    "attachment; filename=" + someFileName);

The problem is that if someFileName had a space in it such as “check this out.txt” then the user would be prompted to download “check_this_out.txt”.

I figured the best option would be to UrlEncode the filename so I tried


But it’s replacing the spaces with plus signs, which stumped me. So then I just tried

and the decode works properly and gives me a space, but the encode takes the space and then gives me the plus sign again.

What am I missing here, is this correct? If so, how should I properly encode spaces into %20’s, which is what I need.


Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Basically both %20 and + are valid ways of encoding a space. Obviously the UrlEncode method has to pick one of the options… if it chose to do the other way, someone else would have asked why UrlEncode(UrlDecode("+")) returned “%20″…

You could always encode it, then just do a straight string replace on “+” for “%20”. I think that would work…

Method 2

I figured the best option would be to UrlEncode the filename

That’s not the right way to put out-of-band characters in a header parameter such as Content-Disposition-filename, and only works (sometimes) in IE due to a bug. Actually it’s a bit of a perennial problem: there is no right way.

If you need to put special characters in the downloaded filename, you can’t do it reliably with Content-Disposition-filename. Instead, omit the ‘filename’ parameter from the Content-Disposition-attachment header, and leave the filename you want in the trailing part of the URL. In the absence of a filename parameter the browser will take it from the URL path, where URL-encoding is the right way to tackle special characters.

Method 3

Quoting from this link

I’ve come across this myself. If you
are able to change the spaces to %20s
then IE7 will convert them correctly.
Firefox though will take them
literally ( at least when using the
Content-disposition header) so you
will need to do this for requests from
IE7 only.

We did the following in our app. ( a
tomcat based document repository)

String userAgent = request.getHeader("User-Agent");
if (userAgent.contains("MSIE 7.0")) {
    filename = filename.replace(" ", "%20");    
    "attachment;filename="" + filename + """);

Method 4

Hi I also faced same kind of problem when downloading the files having spaces in them.

Please see the link which best suites and gives the complete answer.


For the sake of understanding I am just adding the ASP.net code how to solve this problem.

string document = @"C:Documents and SettingsGopal.AmpoluMy DocumentsDownloads" + "Disciplinary & Grievance Procedures..doc";
string filename = "Disciplinary & Grievance Procedures..doc";

Response.ContentType = mimeType;
Response.AddHeader("Content-Disposition", @"attachment; filename=""" + HttpUtility.UrlDecode(filename) + @"""");

From the above you can see that while adding header to the response, filename is enclosed with double quotes.
Please make sure that the “filename” must be Decoded with UrlDecode.

Method 5

One more option is also there, if you can intimate clients about windows hotfix update available at following:

Windows Hotfix Update for IE white space issue

It is client side, so may not be applicable to all the scenarios but still an option if feasible.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x