The question seems somewhat vague to me, so here is what I interpret (also from the code in the fiddle-images in your question):      
- you receive a Blob(image's binary data) through aXMLHttpRequest()GET-request (responseType = 'blob')
- you create a Blob URLwithURL.createObjectURL()in theURL StoreforXMLHttpRequest()response-object (theBlobholding the binary data)
- you set the resulting Blob URL-string assrcfor a image (and append the image to the document, thereby showing the image you just downloaded)
- You "don't want it to work in new tab" ("it" being the Blob URL-string I assume).
In your comments you say:      
- 
- In fiddle I inspected the image and copied the src and then pasted it in new tab and it worked and showed the image I don't want the image to be shown directly with the blob url.  
 
- 
- If you go to youtube and open the src of video in new tab : It will not work,, I want this to happen 
 
It appears to me that you do not want the user to be able to view/download the blob when they copy the Blob URL-string (by examining the live source or simply right-click-on-image>>Copy Imagelocation) and paste it into a new tab/window (for which you give youtube as an example).
But you are also talking about video's.
TL;DR: It seems your question/bounty might be mixing up 2 different types of URL returned by window.URL.createObjectURL();:     
- Blob URLreferencing (objects that represent) 'raw local data' (like (Local-)File, Blob, etc.)
 For these you want to automatically (or programmatically) revoke the- Blob URLfrom the browser's- URL Store(which you could consider a simplified local webserver inside the browser, only available to that browser).
- MediaSource object URLreferencing a special MediaSource Object
 These URL's are- 
- only intended to link srcof aHTMLMediaElement(think<audo>&<video>elements) to the specialMediaSource Object
 Note: a new tab/window is not anHTMLMediaElement
- already automatically revoked
 Note: even though they are created throughwindow.URL.createObjectURL();
 
Here's what's happening for the fiddle in your question's image and similar code that downloaded a video as Blob (where you downloaded the whole video-file's data/binary on the server using an xhr) or any other 'local' data:
You are essentially using the 'bare' 'un-enhanced' File-API.
The URL Store is only maintained during a session (so it will survive a page-refresh, since it is still the same session) and lost when the document is unloaded.
So, if your fiddle is still open, then fiddle-document (the document that created the Blob URL) is obviously not yet unloaded, and therefore it's Blob URLs are available to the browser (any tab/window) as long as it is not revoked!
This is a relevant feature: you can build/download/modify a Blob in the browser, create a Blob URL and set it as href to a file-download link (which the user can right-click and open in a new tab/window!!)
Close the fiddle or revoke the Blob URL from the URL Store and the Blob URL is no longer accessible (also not in a different tab/window).      
Try yourself with your modified fiddle: https://jsfiddle.net/7cyoozwv/
In this fiddle it should now no longer be possible to load your sample image into a different tab/window after you copied the image url (once the image is displayed in your page).
Here I revoked the URL manually (revokeObjectURL()) as it is currently the best cross-browser method (partially due to the api not yet fully being stabilized).
Also note: an element's onload event can be an elegant place to revoke your Blob URL.
Here is what's happening to an <audio> or <video> source linked to an MediaSource Object using an MediaSource object URL returned by window.URL.createObjectURL(MediaSource):
The Media Source Extensions (MSE) also extend the File-API's window.URL.createObjectURL() to accept a MediaSource Object. The (current draft of the) URL Object Extension specifies that:
This algorithm is intended to mirror the behavior of the createObjectURL()[FILE-API] method with autoRevoke set to true.
Note that the current spec of the File API's window.URL.createObjectURL() no longer has an autoRevoke (or flag_oneTimeOnly) boolean flag accessible to the programmer who should be using window.URL.createFor() for this purpose instead. I wonder when the Media-Source spec will mimic that (and for backward compatibility alias their createObjectURL() to a new createFor() extension (seems more appropriate as that is how it seems to be intended to work currently)). 
These resulting automatically revoked URL-strings are only intended to link the src of a HTMLMediaElement (think <audo> & <video> elements) to the special MediaSource Object.
I don't think that an empty Document (from a new tab/window) is a <audo> or <video> element. 
Perhaps "A quick tutorial on MSE"(source: MSDN) might help clarify the difference and basic use:
To use the MSE API, follow these steps:
- Define an HTML5 videoelement in the HTML section of a page.
- Create a MediaSourceobject in JavaScript.
- Create a virtual URL using createObjectURLwith theMediaSourceobject as the source.
- Assign the virtual URL to the video element's srcproperty.
- Create a SourceBufferusingaddSourceBuffer, with the mime type of the video you're adding.
- Get the video initialization segment from the media file online and add it to the SourceBufferwithappendBuffer.
- Get the segments of video data from the media file, append them to the SourceBufferwithappendBuffer.
- Call the playmethod on the video element.
- Repeat step 7 until done.
- Clean up.
You (or a big-time player like youtube who will dynamically select supported technologies for playback on the client's platform (so there is no way to tell for sure what kind of youtube video URL's you are talking about)) could be using the new special MediaSource Object to play video's (or audio).
This adds buffer-based source options to HTML5 video for streaming support (compared to to downloading a complete video file before playing or use an add-on like Silverlight or Adobe Flash to stream media).
Hope this is what you were after!