More than half of Shopify storefront traffic is mobile, and most image protection setups do not cover it at all. The merchant installs a right-click blocker, tests it on their laptop, sees the context menu suppressed, and calls the job done. Meanwhile every phone visitor can press and hold any product photo and tap "Add to Photos" or "Download image" from the menu that pops up. The desktop door is locked. The mobile door, the one most visitors actually walk through, is wide open.
This guide covers why mobile save works differently, the snippet that closes it, the iOS Safari quirk that silently breaks naive versions of that snippet, and the honest limits that apply to all of it. Same rule as always applies: everything here is deterrence against casual saving, not a lock against determined scrapers. Mobile or desktop, the image URL stays public.
Quick facts
More than half of Shopify storefront traffic is mobile, and most image protection setups do not cover it. Desktop right-click blockers do nothing about the phone pathway: long-press save. Closing it takes a touchstart handler (mind the passive-listener trap), a fix for the iOS Safari quirk that breaks naive blockers, and a five-minute test on a real phone. Mobile blocking, like all storefront blocking, deters casual saving only; it does not stop screenshots or a determined visitor.
Why mobile save is a different pathway
Desktop image theft goes through two events: contextmenu (right-click) and dragstart (drag to desktop). Mobile browsers fire neither. The mobile save pathway is the long-press: the visitor presses and holds on an image, the browser surfaces a callout menu, and one tap saves the file. Under the hood this begins with the touchstart event, sometimes followed by browser-native gesture handling that never reaches your JavaScript at all.
That is why a standard right-click blocker does nothing on a phone. It is listening for an event mobile browsers never send. The block has to target the touch events directly, and that is where the complications start.
The touchstart snippet (and the passive trap)
The minimum mobile block for a Shopify theme, pasted before the closing body tag in layout/theme.liquid:
<script>
document.querySelectorAll('img').forEach(function(img) {
img.addEventListener('touchstart', function(e) {
e.preventDefault();
}, { passive: false });
});
</script>The part that trips people up is { passive: false }. Modern browsers treat touch listeners as passive by default, meaning your preventDefault call is silently ignored to keep scrolling fast. Without that flag, the snippet looks installed, throws no errors, and blocks nothing. It is the single most common reason merchant-written mobile blockers do not work, and no console warning tells you why.
Second catch: this attaches listeners to images that exist at page load. If your theme loads products dynamically (infinite scroll on collections, AJAX quick-view galleries), new images arrive without listeners. Either re-run the attach after dynamic loads, or delegate from the document with a target check. For a static product page the simple version above is fine.
The passive listener trap is invisible: the snippet installs, throws nothing, and blocks nothing. Half the mobile protection failures we see come down to one missing flag.
The iOS Safari quirk that breaks naive blockers
iOS Safari adds its own layer. Alongside touch events, it implements the long-press image callout as a native gesture that can fire even when touchstart is suppressed, depending on iOS version and whether the image sits inside a link. Two CSS properties close the remaining gap:
<style>
img {
-webkit-touch-callout: none;
-webkit-user-select: none;
}
</style>-webkit-touch-callout: none disables the iOS press-and-hold callout menu specifically. It is Safari-only, it is exactly what it sounds like, and most tutorials skip it because they were tested in Chrome on Android. The complete mobile block is the JavaScript snippet plus these two CSS lines. Neither alone covers both platforms.
One honest trade-off to weigh before shipping this: suppressing touch behavior on images can interfere with pinch-zoom on product photos in some theme lightboxes. Shoppers zoom into product photos constantly on mobile, and breaking that costs more sales than image theft ever will. Test your zoom after installing, and if it breaks, scope the block to collection-page thumbnails and leave the product-page lightbox alone.
Three mobile protection mistakes
The failure patterns we see most, in order of frequency.
- 01Testing only on desktop. The merchant installs a blocker, verifies on a laptop, ships. Nobody long-presses a product photo on a real phone until a competitor's clone store shows up. Test on an actual iPhone and an actual Android device, not the browser's device emulator, which does not reproduce native gesture handling.
- 02Forgetting the passive flag. The touchstart listener silently does nothing without
passive: false. No error, no warning, no block. - 03Breaking pinch-zoom and not noticing. Aggressive touch suppression kills product photo zoom, quietly hurting mobile conversion. Always test zoom on the product page after any touch-event change.
A five-minute mobile test checklist
After installing any mobile protection, on a real phone: long-press a product image on the product page, expect no save menu. Long-press a collection page thumbnail, expect no save menu. Pinch-zoom the product photo, expect zoom to still work. Scroll a long collection page, expect smooth scrolling (janky scroll means a passive-listener problem in reverse: someone made scroll-blocking listeners non-passive globally). Open the image in the theme's lightbox and long-press there too, because lightboxes often render a fresh image element without your listeners.
Five checks, five minutes, on iOS and Android both. If all five pass on both platforms, your mobile pathway is as closed as client-side blocking can make it.
When the app version earns its place
The snippets above are free and they work. Viking Watermark's anti-theft layer handles the same mobile coverage automatically: touchstart with correct passive handling, the iOS callout suppression, dynamically loaded images, and per-theme gallery quirks, all behind one toggle, tested across Dawn, Crave, Sense, Studio, and Spotlight. Anti-theft is included on every plan including Free. And because the app also watermarks, the photos keep your name on them even when someone bypasses every block with a screenshot, which no snippet can prevent. Install Viking Watermark free if you want the maintained version instead of the hand-rolled one.
For the wider picture of which protection layers exist and which are worth paying for, our studio's image protection guide on Aegis maps the full stack.
Frequently asked questions
Why does my Shopify right-click blocker not work on mobile?
Because mobile browsers never fire the contextmenu event it listens for. The mobile save pathway is the long-press, which starts with touchstart and, on iOS, a native callout gesture. Blocking it requires a touchstart listener with passive set to false, plus the webkit-touch-callout CSS property for Safari.
What is the passive listener problem in mobile image blocking?
Browsers treat touch listeners as passive by default, which means preventDefault is silently ignored. A touchstart blocker without { passive: false } installs cleanly, throws no errors, and blocks nothing. It is the most common silent failure in hand-rolled mobile protection.
Does blocking long-press break pinch-zoom on product photos?
It can, depending on the theme's lightbox implementation. Since mobile shoppers rely on zoom heavily, always test pinch-zoom after installing any touch-event blocker. If zoom breaks, scope the block to collection thumbnails and leave the product-page lightbox alone.
Can visitors still screenshot my product images on mobile?
Yes, always. No app or snippet can block a device screenshot. This is exactly why watermarking matters as a second layer: the screenshot carries your mark even when every blocking pathway is bypassed.
Do I need different code for iOS and Android?
Mostly shared, with one iOS addition. The touchstart listener covers both platforms. iOS Safari additionally needs -webkit-touch-callout: none in CSS to suppress its native press-and-hold callout menu. Android Chrome does not use that property but is covered by the JavaScript listener.
Does Viking Watermark handle mobile image protection automatically?
Yes. The anti-theft toggle covers desktop right-click, drag-save, and the mobile long-press pathway including the iOS callout and dynamically loaded images, on every plan including Free. It is the same deterrence as the snippets in this guide, maintained and theme-tested so you do not have to be.
Is mobile image protection worth it if determined scrapers can bypass it anyway?
For brand-shot photography, yes. Most theft is casual, and the long-press save is the most casual pathway of all, sitting one thumb-hold away from most of your traffic. Closing it costs a few lines of code or a free app toggle. Just pair it with a watermark so the images that do escape still carry your name.