loading...
Cover image for Protecting images on your website

Protecting images on your website

colbyhemond profile image Colby Hemond ・2 min read

While this is not going to completely stop your images from being ripped off of your website, it will help prevent someone from using the common ways they would usually get an image save to their computer. This article will go over the two common ways people save images from a website to their personal computer, and how to prevent it from occuring:

  1. Right click and copy/save
  2. Drag and drop

Right Click and Copy/Save

When you right-click on an image, a context menu appears giving you several options. One of those options being "Save Image As", allowing the user to save a copy of that image to their local computer. Another option being "Copy Image", which allows the user to copy the image and then paste it in a word document. In order to prevent someone from having access to the right-click menu with these options, you can add oncontextmenu="return false" to the HTML element that you want to disable the menu from.

Adding it directly to the <img> tag will limit the disabled context menu to only that image.

<img src="..." alt="..." oncontextmenu="return false"/>

If you have a more sophisticated component on your web page that may contain multiple images, you can also add it to that parent element so that the property is inherited to each <img> tag that is a child of that element.

<div oncontextmenu="return false">
    <img src="..." alt="..." />
    <img src="..." alt="..." />
    <img src="..." alt="..." />
</div>

Keep in mind, this will also not display for any child elements, not just images. So if there is something the user would need access to the context menu for, you would need to to specify oncontextmenu="return false" for only the child elements you need it disabled for.

Drag and Drop

It is just as simple to click and hold on the image, and drag it to the desktop or folder.

In order to prevent this action add the following CSS:

img {
    pointer-events: none;
}

Hopefully this helped you get a little closer to keeping your images secure on your website. Of course these are not a sure fire way to secure them, but it's a good start.

Posted on by:

colbyhemond profile

Colby Hemond

@colbyhemond

Web Developer! I love ice cream, whiskey, and craft beer. Snowboarding and Mountain biking keep me in shape.

Discussion

markdown guide
 

If you asked me to steal some photos, I would boot up chrome developers tools, inspect the photo, get the src and boom!

As you said, you cannot completely stop it.

 

I've seen on some websites feature that when you go to the dev tools, image source is just a bunch of code, so you can't download it, then the only option left is prtscr.

 

Yeah, some devs convert images to base64 and put that image in there directly, you can do it webpack yourself, but it increases the size of final file(html and/or css) and it can be converted back to a file format.

 

Haven't seen any of those yet. And yes, prt + scr is a decent option all though you will lose some significant amount of pixels.

 

haha same here! If someone really wants the image, they will get in one way or another!

 

I’m sure this article will be useful to people asked to implement this feature by their employer, but it’s a futile endeavor. Most people explore the web on their phones, where a button push can capture all the contents of the screen. It’s just a few more buttons to do the same on desktop. And of course developers can just inspect the source and network.

 

Reminds me of the requirement my team had to prevent the apk file from being sideloaded on rooted Android phones. We tried explaining that "root" could be accomplished a million different ways, but evidently there was some sort of requirement from on high that we do what we can no matter what (maybe from hospital guidelines? or an interpretation of hipaa?). We also couldn't test this on our in house devices as that would break our usage agreement we took as employees to not do shady stuff that would void warranties and whatnot with company equipment.

Apparently there was an npm package that can look for the most popular root jars and let you block login based on that. If the project wasn't shelved, I imagine modern permission systems wouldn't let you just casually traverse the installed apps for SuperSU or whatever. I ended up rooting my Samsung S3 just to try being nefarious with our apk to make everyone happy that we have blocked root users.

 

Totally futile indeed ... if you're really intent on protecting your stuff then code an old fashioned executable or make a native app, don't make a website.

 

Absolutely! Maybe I'll dig in to figure out those other levels of security!

 

The image itself has to be watermarked tbh. Because anything over the wire can be inspected and so therefore out in the open.

 

Perhaps the best advice I can give, "dont upload images which you want to keep safe" 🙄

 

But why would you jump though these hoops just to make it more difficult for people to download an image? While (as you're of course aware) people with a tiny bit of knowledge about Chrome Devtools can still download your image in less then 30 seconds.

The web is ultimately about openness and sharing. All this does is irritate simple users of your website while doing nothing to stop the "bad guys". It would annoy me if these techniques would become a trend on the web (but I don't think they will).

 

Does everyone remember the feature built into every browser that's decades old? It's not "image save as", it's "File save as". Saving the file = saving all of the images and assets along with it. And it's saved into neat folders on your local machine.

I see two major problems with encouraging clients to think that they can prevent someone taking images:

  • You can never stop browser features like File Save As - and this is not a developer-hack, this is a feature that every non-technical user can access
  • You are misunderstanding how the internet works. The internet is a file-sharing platform. The images that you see on the browser have already been saved internally on the device - That's just the way it works. To think you can then prevent someone from downloading the image is a fallacy.

Demonstrating that all resources are first downloaded on the user's machine before viewing the website in the browser

 

A lot of people in the comments correctly talking about the futility of this. I would turn it toward embedding unique metadata in your images. If they're copied somewhere and no one would ever come across that service or person, then whatever. I would think the concern is your images get copied into a popular or competitive service.

In that case, you can use a watermark or something like exiftool to embed some metadata into your image. Like a comment with a unique tag. So if it does come up somewhere else, you can yourself download it, verify it is your original image, and send a DMCA notice.

This is assuming the other party doesn't strip metadata from the image when using it, but I feel that's less likely than removing a watermark. People act in bad faith, though, so you kind of have to live with it and understand that about your images.

 

This will still be sending an image over http as a request/response, if you want to really avoid it, maybe have some JS that reads an obfuscated bytestream to a canvas.

 

Lots of added complexity for zero benefit, can be trivially circumvented with canvas.toDataURL().

 

Persuade your employer that trying to do this is a waste of resources that is worse than useless, due to degraded user experience.

If the image assets are the business (e.g. selling artwork or stock photos), providing preview versions at lower resolution, in a lossy format (such as JPG vs SVG for vector graphics), or with a subtle watermark would all work.

There's also hotlink protection, which is another thing entirely, and might make sense to do if you want to avoid data transfer costs from other sites linking to your images.

 

Absolutely! Maybe I'll dig in to that to figure out that next layer of security!

 

An alternative title to this post: "Stopping the rain with your fingers"

 

I'm genuinely interested in why you'd do this. What are some use cases?

If you're trying to stop theft or redistribution of images, realise that you have already given the images to the thief. The browser is their program, on their computer, in their house. You sent an image to that program, along with the HTTPS negotiated keys to decrypt it.
Your domain ended at the Nginx server.

So maybe just don't give your images away in the first place? Sending the client watermarked or lower-res copies.

I can think of a few business-level reasons you might want to do this though (eg. funnel users to the correct downloading UI), why would you do it?

 
 

Huh I didn’t know about oncontextmenu, very cool 👍

 

Good to know these exists 👍🏼

 

That's cool for rick-clicking but will it prevent the image from appearing in the page source or the dev tools in the browser? I've never seen an image for up with a url path of "..." in the source

 

Thanks for reading!

The image will still appear in dev tools. But unless they are a developer, they probably don't know about dev tools. I was writing this as a first line of defense against the casual user.

And I used "..." in the source because I didn't want to make up an image name, the import part was the oncontextmenu="return false"