Stop image saving on mobile in Shopify

August 16, 2026
Image Management
11 min read
a smartphone displaying a product photo with a fingertip pressing the screen and a small shield hovering over the image

You cannot reliably stop image saving on mobile, and the reason is specific enough to be worth knowing: Safari on iOS does not support the contextmenu event at all. Not partially. It does not fire. So the right click blocking script you added to your theme, the one that works perfectly on your laptop, does exactly nothing when a shopper long presses a product photo on their iPhone and taps Save to Photos.

Android Chrome is a different story. It does fire the event, so the same script works there. Which means most Shopify stores currently have image protection on roughly half their mobile traffic and no idea which half.

This post covers what genuinely works per platform, what costs you accessibility or Google indexing, and the one approach that survives every device because it does not depend on the browser cooperating.

In this post

Why your desktop code does nothing on iPhone

Every “protect your Shopify images” tutorial gives you the same snippet: listen for contextmenu, call preventDefault(), done. On a desktop that works. On iOS it is dead code.

MDN’s browser compatibility data records the event as unsupported in Safari on iOS. The WebKit bug tracking it was filed in July 2020 and is still open. A WebKit engineer commented on it in 2021: “As far as I am aware, there is no mainstream UI way to trigger a contextmenu event in iOS WebKit.” There is one odd exception, an iPad with a Bluetooth mouse attached, which is not your traffic.

What the iPhone user sees instead is the native long press sheet: Save to Photos, Copy, Share, Add to Photos, and on recent versions the ability to lift the product straight out of the background and into their clipboard. Your JavaScript never gets a say, because the browser never asks it.

That is the whole diagnosis. Now the treatments, from most useful to most damaging.

What actually works on iOS

The one documented lever is a CSS property that controls “the default callout shown when you touch and hold a touch target”. Add it to your images, along with selection blocking on the parent, which is the combination developers report as most reliable.

.product-media,
.product-media img {
  -webkit-touch-callout: none;
  -webkit-user-select: none;
  user-select: none;
}

This goes in Shopify’s native Custom CSS field, under Theme settings in the theme editor. No code editor needed, though remember the field is capped at 1,500 characters for the whole theme.

Three honest caveats, because this property is not the reliable fix it looks like:

  • MDN labels it non standard and warns against production use. It works in Safari on iOS and iPadOS only. Not Chrome, not Firefox, not even Safari on a Mac.
  • It is flaky on current iOS. An Apple developer forum thread from November 2025 reports it failing on iOS 26.1 even with !important, and Apple has not replied.
  • Adding -webkit-user-select: none earns you a side benefit that WebKit shipped in late 2021: it also suppresses the iOS text magnifier on those elements.

Test it on a real iPhone, not a simulator, and test after every iOS release. That sentence is annoying and it is also the job.

What works on Android

Chrome on Android does fire contextmenu on a long press, so the standard snippet works. Scoped to images so you do not break normal link behaviour:

document.addEventListener('contextmenu', function (e) {
  if (e.target.tagName === 'IMG') e.preventDefault();
});

That removes Download image and Search image with Google Lens from the long press menu. Note that -webkit-touch-callout does nothing here, since Chrome never implemented it, so Android needs the script and iOS needs the CSS. You need both, and there is still no standard cross browser property for this: a proposal to add one was opened with the CSS Working Group in May 2025 and is still unresolved.

The full walkthrough for the script side, including where it goes in theme.liquid, is in how to disable right click on Shopify.

The overlay trick and what it costs

When the CSS fails, people reach for one of two hacks. Both work. Both cost more than they are worth.

The transparent overlay. Put an empty div on top of the photo so the long press lands on nothing. The image tag stays in the DOM, so alt text and Google Images indexing are untouched, which makes this the least bad option. The cost is interaction: your overlay is now between the shopper and the image, so lightboxes, pinch to zoom galleries and tap to enlarge all need rewiring through it. Watch out for WCAG 2.4.11 as well, which says a focused component must not be entirely hidden by author created content.

The CSS background image. Replace the image tag with a div carrying a background image. Apple confirms background images cannot be saved through the normal path, so it genuinely works. It also removes your product photos from Google Images entirely, because Google states plainly that it “doesn’t index CSS images”, and it creates a real accessibility failure, catalogued by W3C as F3, because you cannot attach alt text to a CSS background.

Trading your image search traffic and your screen reader users for a marginally harder save is a bad deal. Do not take it.

Pointer events none is the third variant and the sneakiest, because it looks clean in a demo. Events pass through the image to whatever sits underneath, so no menu appears, and every click handler on that image dies with it. Product galleries stop working. Test before you ship it.

The one thing you must not do

Do not block pinch zoom to stop people zooming in and screenshotting.

A viewport tag carrying user-scalable=no or maximum-scale=1 fails WCAG success criterion 1.4.4 Resize Text, and W3C publishes a test rule specifically for it. Unlike everything else in this post, that is not a judgement call or a usability opinion. It is a documented accessibility failure that an automated audit will flag, and it locks out shoppers with low vision who need to zoom to read your product details.

Same for touch-action: none, which MDN warns “may inhibit operating a browser’s zooming capabilities”, with the same consequence.

And it does not even achieve the goal, since the screenshot button does not care about your viewport tag. You would be failing an accessibility criterion for nothing.

The layer that works on every device

Step back and look at what all of the above has in common: every technique depends on the browser choosing to cooperate. iOS does not. Extensions do not. Screenshots never did. And Shopify’s CDN hands out the full resolution original to anyone who requests the URL, with no referrer checking and no signed URLs, which we verified with live requests while researching the desktop side of this.

Shopify says it themselves, under a heading called “Protect your images”: “You can’t prevent people from saving your on-screen images, but you can use an app from the Shopify App Store to add a watermark.”

That is the platform telling you where the ceiling is. A mark burned into the pixels does not care which browser, which OS version, or whether the file arrived by screenshot, download or scraper. It travels with the file. And in the US, a mark carrying your business name can count as copyright management information, where removal carries separate statutory damages of $2,500 to $25,000 per violation, which is a lever no CSS property will ever give you.

Doing that across a catalog is the practical problem, so bulk it: Viking Watermark stamps your logo across a collection or the whole catalog and blocks right click, copy and drag save from a theme embed, keeping originals in Shopify Files so any product restores in one click. Storefront protection and restore are on the free plan, paid plans start at $5 a month, and it holds 5.0 stars from 6 reviews, a young rating rather than a proven one.

Storefront protection blocking right click and image saving across a Shopify store on mobile and desktop

The developer also has a walkthrough of the mobile specifics on their own blog, which is worth a read before you decide how far to take the blocking side.

A realistic mobile checklist

  • Add the callout and selection CSS for iOS, and accept that it may stop working after an iOS update
  • Add the scoped contextmenu listener for Android
  • Never touch the viewport zoom settings
  • Keep the primary feed image clean, mark gallery shots two and three
  • Test on a real iPhone and a real Android handset, then again after each OS release
  • Keep an unmarked master of every hero shot for reverse image searching later

While you are testing on a phone, look at the rest of the mobile experience too. Our free product image audit flags missing alt text and thin galleries, the image compressor deals with the heavy files that make mobile pages crawl, and there is more in mobile product page optimization.

Two neighbouring mobile problems worth naming while you are in there: tapping a colour and getting the wrong photo is variant image filtering work, and a collection page showing the same product in six colours as six cards is what combined listings fix.

FAQ

Can I stop someone saving my product images on an iPhone?

Not reliably. Safari on iOS does not support the contextmenu event, so scripts cannot intercept the long press. The CSS property -webkit-touch-callout: none is the documented option, but it is non standard and there are open reports of it failing on current iOS versions.

Why does my right click blocking work on desktop but not mobile?

Because the event you are blocking does not exist on iOS. Desktop browsers and Chrome on Android fire contextmenu, and Safari on iOS never does. Your code is correct, it simply has nothing to listen to on an iPhone.

Does using a CSS background image instead of an image tag work?

It stops the normal save path, and it costs too much. Google states it does not index CSS images, so your product photos leave Google Images, and CSS backgrounds cannot carry alt text, which is a documented accessibility failure. Not worth it.

Will blocking long press hurt accessibility?

Blocking the callout itself does not breach a specific WCAG criterion, since the browser menu is user agent functionality. Blocking pinch zoom does breach one, failing success criterion 1.4.4, and an overlay that hides a focused element can breach 2.4.11.

Can I stop screenshots on mobile?

No. Screenshots are an operating system function and no web page can detect or block them. This is the reason a visible watermark is the only protection that keeps working after the image leaves your store.

Does an app do this better than my own code?

For the blocking half, an app mostly saves you maintaining the code through theme updates and OS changes. The real difference is the watermarking half, which no snippet can do, since it has to modify the image files themselves and keep restorable originals.

Pick up your phone, open your best selling product, and long press the hero shot. Whatever appears next is your actual protection level, not whatever the tutorial promised.

Protect the file, not the browser →

Co-Founder at Craftshift

You may also like