Shopify Video Autoplay Not Working on Mobile: the muted and playsinline Fix

The video plays on your laptop, loops nicely, looks great. On your phone it sits there as a still with a play button in the middle. Or it plays but opens full-screen and hijacks the page. Or it plays on one phone and not another.

All three come from the same place: mobile browsers apply strict rules to autoplay, and Shopify's default markup does not always satisfy them. The fix is a specific set of attributes, plus an understanding of the cases where no attribute will help. This guide covers both, with the Liquid you need if you are editing a theme.

For the broader question of where video belongs on product pages before you worry about autoplay, the shoppable video setup guide is the place to start.

The rule every mobile browser applies

Since iOS 10, Safari on iPhone and iPad only autoplays a video if it has no audio track or is explicitly muted, and it only plays inline (inside the page rather than in the full-screen player) if the element says so. Chrome on Android follows the same muted rule. Neither will autoplay with sound before the user has interacted with the page.

So the minimum markup for a video that autoplays silently inside a Shopify page on a phone is:

```html

<video autoplay muted loop playsinline preload="metadata" poster="poster.jpg">

<source src="video.mp4" type="video/mp4">

</video>

```

Four attributes do the work:

• autoplay asks the browser to start playback.
• muted satisfies the no-sound rule. Without it, iOS and Android ignore autoplay entirely.
• playsinline tells iOS to play within the page. Without it, an autoplaying video on an iPhone either does not start or jumps into the native full-screen player.
• loop keeps a short clip going, which matters for product loops but is optional.

poster and preload are not part of the autoplay rule, but they decide what the shopper sees in the cases below where autoplay is blocked anyway, so treat them as required.

Why Dawn shows a poster and waits

If you are on Dawn or a theme derived from it, the product gallery does not autoplay video at all, and that is by design rather than a bug.

Dawn wraps every gallery video in a <deferred-media> custom element. It renders the poster image with a play button, and only injects the <video> markup when the shopper taps. That keeps the initial page light, which is the right trade for a gallery that might hold six images and a video.

Dawn's Video section behaves the same way: cover image, play button, load on tap. If your theme version adds an autoplay toggle to that section, it will emit the muted and inline attributes for you; if not, the section will never autoplay no matter how the file was exported.

Horizon is block-based and its video block carries playback settings in the theme editor. Check the block's settings panel for autoplay and loop toggles, and confirm on a real phone, because the block still has to obey the same browser rules described above.

So the first question is whether you actually want gallery autoplay. For a product-in-use clip inside the gallery, tap-to-play is often fine. For a reel or UGC clip you want moving as the shopper scrolls, use a container built to autoplay: either a template edit as below, or an app block.

The Liquid that emits the right attributes

Shopify's video_tag filter renders a <video> element for a hosted video media object and accepts playback attributes as parameters. The form that works for silent mobile autoplay is:

```liquid

{{ media | video_tag:

image_size: '800x',

autoplay: true,

muted: true,

loop: true,

controls: false,

preload: 'metadata' }}

```

image_size sets the poster image width. After saving, view the rendered HTML on the storefront and confirm playsinline is present on the element. If it is not, the more explicit route is to write the tag yourself and loop over the media's sources:

```liquid

{% if media.media_type == 'video' %}

<video autoplay muted loop playsinline preload="metadata"

poster="{{ media.preview_image | image_url: width: 800 }}"

aria-label="{{ media.alt | escape }}">

{% for source in media.sources %}

{% if source.format == 'mp4' %}

<source src="{{ source.url }}" type="{{ source.mime_type }}">

{% endif %}

{% endfor %}

{% for source in media.sources %}

{% if source.format == 'm3u8' %}

<source src="{{ source.url }}" type="{{ source.mime_type }}">

{% endif %}

{% endfor %}

</video>

{% endif %}

```

Two things in that snippet are deliberate. The MP4 sources come before the HLS (m3u8) source, and the poster comes from the media's preview image rather than being left blank. Both matter on mobile, for reasons covered next.

If you are editing Dawn specifically, the gallery markup lives in snippets/product-media.liquid (older versions) or snippets/product-thumbnail.liquid (newer versions). Replace the <deferred-media> wrapper for the video case with the raw <video> above, on a duplicate theme, and test before publishing.

Source order: MP4 before HLS

Shopify transcodes each hosted video into several MP4 renditions and an HLS stream. Safari plays HLS natively. Chrome on Android and most desktop browsers do not.

A <video> element tries sources in order and stops at the first one it can play. If the HLS source is first, Safari is happy and Chrome has to fall through. That usually works, but combined with preload="none" and autoplay, we have seen Chrome stall on the first source and never start. Listing MP4 first removes the ambiguity: every browser can play it, and Safari still gets a working stream.

If you are pulling the video URL from the admin (the media's "Copy link" option) rather than Liquid, make sure you copied the .mp4 rendition and not the .m3u8.

Setting muted from JavaScript

This one catches developers rather than merchants, but it explains a lot of "the attributes are there and it still does not play" reports.

When a page builder, app or theme script creates the video element in JavaScript and sets muted as an attribute after the element is attached, some browsers do not treat the element as muted for autoplay purposes. Chrome in particular has had this behaviour for years. The reliable pattern is to set the property, not just the attribute, before calling play(), and to handle the promise play() returns:

```js

const v = document.querySelector('video[data-autoplay]');

v.muted = true;

v.playsInline = true;

const p = v.play();

if (p !== undefined) {

p.catch(() => {

v.controls = true;

});

}

```

The catch matters. On a phone in Low Power Mode, play() rejects. If you ignore the rejection the shopper sees a frozen frame with no way to start it. Turning controls on in the catch gives them a play button.

If you inspect a video in Safari's Web Inspector and it has the muted attribute but video.muted reports false, this is the problem.

The blockers no markup can fix

Some share of your mobile visitors will never see autoplay, and you should plan for them rather than chase them.

iOS Low Power Mode. When the battery saver is on, iOS suppresses autoplay and shows the play button overlay. It is per-device and you cannot detect it. Many people leave it on permanently.

Chrome Data Saver and Lite mode. Same effect on Android. The browser decides not to fetch media until asked.

Reduce Motion. Some browser versions honour the OS accessibility setting for autoplaying video. Dawn already adds a motion-reduce class and respects prefers-reduced-motion in CSS; if you write your own markup, do the same.

In-app browsers. Instagram, TikTok and Facebook open links in their own web views. They generally honour the muted-inline rule, but they are also where you will see the widest variance. Test your product page by tapping a link inside the Instagram app, not only in Safari.

The design response to all of these is the same: a real poster frame that looks intentional as a still, and a visible play control. If the still looks like a broken video, the fallback experience is worse than having no video at all. The phone product video guide has notes on choosing a first frame that reads as a photo.

Testing and the fallback experience

On real devices

Desktop device emulation is where most autoplay bugs hide. Chrome's mobile emulation resizes the viewport and changes the user agent, but it does not apply iOS autoplay policy, Low Power Mode or Data Saver. A video that autoplays in emulation tells you nothing about an iPhone.

The setup that does tell you something:

• iPhone plus a Mac. Enable Web Inspector on the phone (Settings, Safari, Advanced), connect by cable, and open Safari, Develop, your phone, the page. You get the full Elements and Console panels for the page running on the actual device. Check the rendered <video> attributes and call document.querySelector('video').play() in the console to see whether it resolves or rejects, and with what error.
• Android plus Chrome remote debugging. Enable USB debugging, open chrome://inspect on the desktop, and inspect the page on the phone the same way.
• Both phones, no cable. Open the page in a private tab, then again with Low Power Mode or Data Saver on, then from a link tapped inside the Instagram app. Three views, three different autoplay outcomes, all legitimate.

Keep a short clip and a known-good page bookmarked so you can confirm the device itself autoplays before blaming your markup.

Poster frames that survive a blocked autoplay

Because some visitors will always see the still, the poster is part of the design, not a fallback.

Export the clip so its first frame is a clean, well-lit shot of the product with the subject centred, or set the poster attribute to a purpose-made image. Avoid a first frame mid-motion; it reads as a broken video. Make sure the poster has the same aspect ratio as the video, or the element will jump when playback starts. And if the video has on-screen text, keep the first frame free of it so the still does not look like a caption with no context.

A useful test: screenshot the page with autoplay blocked and ask whether it still looks finished. If it does, the fallback is fine.

Autoplay and page speed

Once autoplay works, the next complaint is usually speed. An autoplaying video near the top of a product page fetches media before the shopper has done anything, and on a slow connection that competes with the product images and the add-to-cart button.

Three habits keep it under control:

• preload="metadata" or preload="none", never auto, so the browser fetches the header and the poster but not the whole file.
• Play only when the element is in view. An IntersectionObserver that calls play() on entry and pause() on exit stops off-screen videos from streaming.
• Keep clips short and encoded for the web. A 15-second vertical clip at 720p is typically a few megabytes; a 4K export of the same clip is many times that and looks identical on a phone.

For a fuller treatment of how video affects Core Web Vitals on Shopify, and what lazy loading changes, see the video and bounce rate article.

When to stop editing the theme

If you have reached the point of writing IntersectionObserver code in a theme snippet, it is worth asking whether an app block would do the same job with less to maintain.

A purpose-built video widget already emits the correct attributes, orders the sources, ships a poster, lazy-loads, and handles the play() rejection with a visible control. It also carries product tagging and add-to-cart inside the player, which a raw <video> element never will. Theme updates do not overwrite it, because it lives in an app block rather than the gallery snippet.

The template edit is right when you have one video, one theme and someone comfortable in Liquid. The widget is right for reels and UGC feeds that change every week. The free shoppable video app comparison looks at what the free tiers actually include if you want to test before committing.