title: window.URL.revokeObjectURL() doesn't release memory immediately (or not at all)?
body: <p>I'm making an html interface to upload images on a server with Drag &amp; Drop and multiple selection files. I want to display the pictures before sending them to the server. So I first try to use <code>FileReader</code> but I have had some problems like in <a href="https://stackoverflow.com/questions/6217652/html5-file-api-crashes-chrome-when-using-readasdataurl-to-load-a-selected-image/6298889#6298889">this post</a>. so I change my way and I decided to use blob:url like ebidel recommends in the post, with <code>window.URL.createObjectURL()</code> and <code>window.URL.revokeObjectURL()</code> to release memory.</p>
  <p>But now, I've got another problem, which is similar to <a href="https://stackoverflow.com/questions/7167180/understanding-object-urls-for-client-side-files-and-how-to-free-the-memory">this one</a>. I want that a client could upload 200 images at time if he wants. But the browser crashed and the ram used was very high! So I thought that maybe too much images were displayed at the same time, and I set up a system with a waiting queue of files using an array, in order to treat only 10 files at time. But the problem still occurs.</p>
  <p>On Google Chrome, if I check <code>chrome://blob-internals/</code> the files (which are normally already released by <code>window.URL.revokeObjectURL()</code>) are released approximately after a 8 seconds delay. On Firefox I'm not sure but it seems like if the files were not released (I check on <code>about:memory</code> -&gt; images for that)</p>
  <p>Is my code which is bad, or is it a problem independent of me? Is there a solution to force the navigators to release immediately the memory? If it can help, this is the part of JavaScripton which the problems occurs: <strong>link expired because code was not included in question</strong>.</p>
  <p><strong>EDIT</strong></p>
  <p><em>This is a kind of own answer + an answer to bennlich (too long text for a comment)</em></p>
  <p>I understood from the answer of user1835582 that I could indeed remove the Blob/File but while the browser needs images it keeps them somewhere in memory (which is logical). So it's the fact to display images (many &amp; heavy) that gave me crashes &amp; slow downs, not the <code>revokeObjectURL</code> method. Moreover, each browser manages the memory by its own way, leading to different behaviors. Here is how I came to this conclusion.</p>
  <p>First, let's try that <code>revokeObjectURL</code> works well, with a simple example using the source code of <a href="https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images</a>.
  Using Chrome you can verify that Blob are well revoked, by checking <code>chrome://blob-internals/</code> or trying to open displayed images into a new tab that will be blank. Note : to fully release Blob references, add <code>document.getElementById(&quot;fileElem&quot;).value = &quot;&quot;</code>. When I posted my question some years ago, it was about 8 seconds to release blob, now it's almost immediate (probably due to improvements in Chrome &amp; / or to a better computer)</p>
  <p>Then, time for a charge test. I did it with a hundred of jpg of ~2.5 Mo each. After that images have been displayed, I scrolled the page. Chrome crashed and Firefox was slow (not tested on others browsers). However, when I commented <code>li.appendChild(img)</code> all went well, even with a huge bunch of images. This shows that problems are not coming from <code>revokeObjectURL</code> method which in fact works properly, but from displaying lot of heavy images. You can also test to create a simple html page with hundreds of heavy images and scroll it =&gt; same result (crash / slow down).</p>
  <p>Finally to look deeper about images memory management, it's interesting on Firefox to look into about:memory. For example I saw that when the window is active, Firefox uncompresses the images (images -&gt; uncompressed-heap goes up), while raw (images -&gt; raw) is always stable (relative to the the quantity of images loaded). There is a good discussion about memory management here : <a href="http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory" rel="nofollow noreferrer">http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory</a>.</p>