You can't screenshot or right click this image

People contact me with all sorts of weird opportunities. Some are fun. Some are not. I've lost count of the number of NFT grifters who've asked me to "revolutionise" the art space. I'm generally not a fan. But I had one chat with someone who wanted to do something intriguing. They were worried about people right-clicking or screenshotting their precious images and had a plan to stop that.

I tried to explain to them that DRM always fails; you can't make data which can't be copied. I explained that artificial scarcity was harmful. They didn't care.

But, their proposed solution was intriguing. And, with their kind permission, I'm posting it here. To be clear, I don't think this is good but I think it is vaguely interesting.


Back in the olden days, video was often interlaced. That is, the TV transmitter would broadcast the odd lines first, then the even lines. Your TV would draw the odd line then, in the millisecond before they faded away from the cathode-ray tube, draw the even lines.

Could we do the same with images?

Let's take this image of a Total Legitimate Bored Ape™
A badly drawn cartoon of a monkey in a t-shirt.

With a scrap of Python, we can knock this into two interlaced images:

from PIL import Image
image ="ape.png")
pixels = image.load()
image.mode = "RGBA"

for y in range(image.height) :
   if (y%2 == 1) :
      for x in range(image.width) :
         pixels[x,y] = (0,0,0,0)"ape1.png")

for y in range(image.height) :
   if (y%2 == 0) :
      for x in range(image.width) :
         pixels[x,y] = (0,0,0,0)"ape2.png")

Which gives us:
Only the odd lines of the image are displayed.

Only the even lines of the image are displayed.

Using JavaScript the first frame can be rendered onto a <canvas> element for a millisecond, wiped, and then the second displayed. Repeat.

Here's a demo of it in action - I kinda like the retro effect!

⚠️ Strobe Effect Warning

If you right click on it, you'll only get half the image. If you take a screenshot, you'll only get half the image. FOOLPROOF DRM!!!!!!

Expanding the complexity

Of course, you can scramble an image before unscrambling it to the canvas and all sort of other tricks. You could have dozens of images rendering to the canvas in sequence. You could draw individual pixels programmatically. You could...

None of it matters of course. If you send pixels to a computer screen, they can be copied. It is possible to slow people down - but all it takes is for one person to work out how your scheme works and then it crumbles to dust.

As I said, I have a soft-spot for the shimmery effect. And I think it is kinda fun - in a code-golf way - to design obfuscation schemes.

But using anything like this for a form of digital restrictions management is daft.

14 thoughts on “You can't screenshot or right click this image

  1. @Edent Back in the olden days we had to do this:<script type="text/javascript"><!--function OnRightClick() { if (event.button==2) { alert ('Sorry, no right clicking allowed.'); }} document.onmousedown=OnRightClick//-->😂

  2. says:

    As ways of trying (and failing) to prevent people copying images go, this is definitely interesting (and retro-looking). However, I have a feeling it would be fairly trivial to reconstruct a good enough version of the original image from one of the interlaced images using Photoshop, or indeed any half-decent image editing app. And that flickering would really bug some people, and perhaps even be painful for a few.

  3. Now I realise I’m commenting while I have a headache, but literally my first thought was to wonder if that could trigger photo-sensitive epilepsy.

    (Also sigh, obviously)

  4. says:

    @Edent this makes me think of tamper-proof seals, with layered foil/adhesive so that if the seal is removed it leaves a warning message behind. You could structure the interlacing in such a way as to hide a message in the image that’s readable when screenshotted. (Obviously ignoring the fact that there’s no real value to doing so.)

  5. says:

    Let's please not ignore how CPU-intensive this kind of implementation is. It requires re-rendering the image every frame (i.e. about 60 times per second), which means it is very unfriendly to battery-powered devices (laptops, phones), and also makes mains-powered devices warmer and louder.

    If you're reading this blog and you're thinking about deploying this "solution" in the wild, please don't.

Leave a Reply

Your email address will not be published. Required fields are marked *