HTML Input Type File Browse Element /FakePath Mystery and Plain Stupid W3C Specification.

11 Nov

From past couple of days I have been working on the piece of code where I have to upload and Preview the image.All upload and preview I wanted it to be on the same page at client side with no server calls happening for previewing the image other than doing a submit.

I was thinking it would be simple stuff where I have a simple HTML Page which will have Input File type element tag which comes with Browse button to pick the file from the desktop and attach the file path to the IMG Element SRC and preview it in the same page for the users.My bad though the logic looks so perfect and  simple, yet its implementation is impossible, given that for the sake of security(Google/Bing/Yahoo Search Says so), all browsers under normal circumstances or in default mode puts the severe restriction on the input type file element capability.Unless we tweak setting in browsers, its not going to display Images with this logic and some browsers just plainly refuse to display it no matter what.

Here is code I wrote so as to upload and preview the image on the same page.Please note that this rough cut of the code and it can altered or changed to fit in the dimensions of the image in the browsers where it works.I have not validated this code for w3c validation.(Sorry for bad formatting of code,but for some reason this is just not working now).


<html dir=”ltr” lang=”en-US”>


<title>Image upload trial</title>

<style type=”text/css”>












<meta charset=”utf-8″>


<div id=”idmaincontainer” class=”clmaincontainer”>

<input type=”file” name=”img” id=”idimgupload” class=”climgupload”>

<img src=”#” id=”my_img” class=”climg ” alt=”Image”/>

<div id=”idimgdisplay” class=”climgdisplay”></div>


<script src=””></script>




var path = $(‘#idimgupload’).val();

path = path.replace(“C:\\fakepath\\”, “”);


$(‘#my_img’).attr(‘src’,path );

alert(“test for bind”);






Now lets start with Microsoft IE, I have been fan of Microsoft for number of years and for various good reasons.One among them is the way they share information about their products via blogs/MSDN/Articles etc.In fact I can go ahead and say that some of best things I have learned is from Microsoft Folks who are in Development/Support/.Net Reverse Engineering/IIS/IE teams etc.

Okay now coming back to this topic,this piece of code works perfectly fine in IE9,IE8,IE7 version of browsers provided we tweak some setting in IE. I have tested it and can see that right after we select the Image file, it displays your image.The setting which one needs to do is

  • Add your site in the IE’s Trusted Site list.
  • Enable the below Setting in IE.Click Tools Bar in IE.Select Internet Options >Security >Custom Level.If you scroll the list of options to enable or disable over there, you should see below option.Enable this option.

Include local directory path when uploading files to a server

Now coming for Firefox/Safari/Google Chrome all latest version at the time of this writing, I can only say that there is some magic happening in Firefox browser,sometimes it works and other times it does not work.But this piece of code surely do not work on Safari/Google Chrome and we get below Fake path message,



Both Chrome and Safari adds the fake path to the actual directory structure in the alert box and in reality looks for the image in the root folder of the application on the  server.So this solution fails with 404 error when viewed via browser developer tools(F12 tools).I can see this in DOM that filename is replaced correctly but path of the file is set to the root of the folder.So basically path is as http://localhost:7000/D3.jpeg

Ok now why do the browser are behaving like this with the element which they wholeheartedly support,below I feel is the reasons for this,

I am not sure as what security holes they are seeing here,of course I am not a hard core expert in programming,but I also know there are very very few guys who can really hack the stuff,but again we should not forget that now a days security companies are coming up with products which blocks just anything and everything if they suspect.Now which so much intelligence around,does it make sense to ignore this solution ?

For every image that is uploaded in the web and previewed in the web,it makes at least 2 calls to the server,one for storing the image to some temp location and other to retrieve the image to preview it.What a waste of bandwidth and money here.

I am also not getting where are client side web performance experts,don’t they see the benefits of this element and changes it can bring to the web once these silly restriction are removed or are they saying that risks outweighs the benefits here ?..


One Response to “HTML Input Type File Browse Element /FakePath Mystery and Plain Stupid W3C Specification.”

  1. Padhoo Nair July 14, 2012 at 1:59 pm #

    Do you know what caused IE’s premature death? It was its stupid security concerns
    Golden Band to block some innocent javascript.. then a confirm dialogue to scare away surfers ets . This one is another such stupidity. The argument is user’s file structure and some identity like ‘documents and settings/Ram Kumar/….’ will be submitted to other peoples’ server. In that case it is the user who should worry about it, he should not keep files to be uploaded in any sensitive locations ‘D:\Uploadables\SomFiles.ext’ is not going to hurt.
    Instead a blanket restriction is rank stupidity

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: