Website Hero Video Size, Format and Autoplay: 2026 Guide

A hero video is the short silent loop behind or beside the headline at the top of a page. No platform sets its size. The browsers set the rules for whether it plays at all, and the page's speed sets the rest.

This guide reads Chrome's autoplay policy, WebKit's video policy for iOS, MDN's reference for the video element and its autoplay guide, web.dev's video performance module and W3C's explanation of WCAG's Pause, Stop, Hide rule, as they stood on 28 October 2026. Where a number is ours, it says so and names the file it came from.

We are a small studio that makes short product films for software and apps, including loops for the top of a website. The last section says how we work; everything before it stands on its own.

The short answer

Whose rules these are

Three kinds of source are quoted here, and they carry different weight. Browser rule marks what Chrome and Safari actually do, from their makers' pages; a video that breaks these rules does not play. Standard marks WCAG, the W3C's accessibility standard. Recommended marks advice from web.dev and MDN, written by browser engineers but not enforced by any browser. Our own numbers are marked as ours.

Two of the pages are old. Chrome's autoplay article was last updated on 13 September 2017 and WebKit's iOS post is dated 25 July 2016. MDN's autoplay guide, updated on 10 September 2026, describes the same behaviour today.

Why a hero video must be muted

Browser rule Chrome's policy starts with the line that decides everything: "Muted autoplay is always allowed." Autoplay with sound is allowed only if the visitor has interacted with the site, has a high enough media engagement score on desktop, or has installed the site. A first visit to a landing page meets none of those.

Safari on iPhone and iPad follows WebKit's policy, which allows autoplay without a tap when the video has no sound: such videos "will be allowed to autoplay without a user gesture if their source media contains no audio tracks", and muted ones "will also be allowed to autoplay without a user gesture." WebKit adds a rule that catches out sites that unmute on scroll: "If a <video> element gains an audio track or becomes un-muted without a user gesture, playback will pause."

MDN's autoplay guide puts the two together: "Autoplay blocking is not applied to <video> elements when the source media does not have an audio track, or if the audio track is muted." So a hero video is muted and silent by design. If the film has a voice or music, the hero is a silent cut of it, and the full film with sound sits behind a play button.

The attributes, one by one

The wording in the middle column is MDN's, from its video element reference (last modified 16 July 2026). The right column is our note for a hero loop.

Browser rule On playsinline, WebKit's post is specific: "On iPhone, <video playsinline> elements will now be allowed to play inline, and will not automatically enter fullscreen mode when playback begins." Without it, a hero that tries to play on an iPhone would want the whole screen. MDN's own example of an autoplaying video notes "the playsinline attribute that is required for autoplay in Safari".

Two traps from MDN, both about how boolean attributes work. For autoplay, "the video will autoplay if the attribute is there in the <video> tag at all", so autoplay="false" still autoplays. For muted, "the audio will be muted if the attribute is present at all."

Size and file weight

No browser or standard sets a size for a hero video. The size is a trade between sharpness on a large screen and the bytes every visitor downloads. Our working answer is 1280 x 720 for a 16:9 loop that fills the width of a desktop page: it is 44% of the pixels of 1920 x 1080, and behind a headline the difference is hard to see.

Our measurement. The loops on our own work page are encoded by our encoding script at 720 pixels on the short side, without audio, and played muted. We read these two live files with ffprobe on 28 October 2026:

The files are lovable-just-say-it-tile-072e86c8.mp4 and notion-in-pieces-tile-b3f3dac2.mp4 on this site; the WebM row is the second command below, run on the same six seconds. Both MP4 loops have flat, designed pictures; a loop of camera footage, with grain and constant movement, needs more bits for the same look. As a rough budget from our files: about 0.12 to 0.13 MB per second of 720p loop as MP4, and less as WebM.

The recipe, run

Recommended web.dev's video module gives the two moves that matter most: drop the audio, because "removing the audio stream reduces the size of the video file, even if the audio stream already present in the source video file is silent", and offer more than one format, with "MP4 can be used as the fallback for legacy browsers." It also warns that source order is priority: "If you specify an MP4 source first, then the browser selects that format regardless of its support for more efficient formats that may be specified."

Our recipe. We ran these commands on 28 October 2026 with ffmpeg 9.0.2, on our 1920 x 1080 Lovable film, cutting the six seconds from 6 s to 12 s. The MP4 command uses the same settings as our encoding script, and its output was byte for byte the live Lovable loop on our work page.

ffmpeg -ss 6 -i film.mp4 -t 6 -an -vf "scale=-2:720,format=yuv420p" \
  -c:v libx264 -preset slow -crf 27 -maxrate 2500k -bufsize 5000k \
  -g 60 -movflags +faststart hero.mp4

ffmpeg -ss 6 -i film.mp4 -t 6 -an -vf "scale=-2:720,format=yuv420p" \
  -c:v libvpx-vp9 -crf 42 -b:v 0 -row-mt 1 hero.webm

ffmpeg -i hero.mp4 -frames:v 1 -q:v 3 hero-poster.jpg

What each part does: -an removes the audio; scale=-2:720 makes it 720 pixels tall and keeps the shape; -crf 27 sets the quality, with -maxrate capping the busiest moments; -g 60 puts a keyframe every two seconds at 30 fps; +faststart moves the index to the front of the file so playback can begin before it has all arrived. The results: hero.mp4 770,197 bytes, hero.webm 496,675 bytes, hero-poster.jpg 40,367 bytes, and neither video has an audio stream. Measured against a lossless cut of the same six seconds, the WebM scored a higher SSIM than the MP4 (0.981 against 0.963): smaller and closer to the source, on this clip.

Then list the WebM first:

<video autoplay muted loop playsinline poster="hero-poster.jpg" width="1280" height="720">
  <source src="hero.webm" type="video/webm">
  <source src="hero.mp4" type="video/mp4">
</video>

One limit of this recipe: it cuts a window out of a longer film, so the last frame and the first frame do not match, and the loop jumps where it repeats. A loop that repeats without a visible jump has to be made that way, with the end built to meet the start.

Loading without slowing the page

Recommended web.dev: "<video> elements with the autoplay attribute specified begin downloading immediately, even if they are located outside of the initial viewport." For a hero at the top that is what you want; for a looping video further down, it is a cost every visitor pays.

• The poster counts for Largest Contentful Paint. web.dev notes that a video's first frame, once painted, "will be considered as an LCP candidate", and advises making sure "video LCP candidates are optimized so that they display as soon as possible if the poster attribute isn't used." A small poster that matches the first frame paints quickly and hides the start.
• Below the first screen, wait. web.dev suggests "combining the poster attribute with the Intersection Observer API" so a video downloads only when it is near the screen, and describes loading="lazy" on video as "a relatively new addition".
• Phones. On our own site, a loop that sits in the first screen does not autoplay on a phone at all, because its file would push a phone visit over the 4 MB budget we set for the first screen. That is our choice, not a rule; the poster shows instead.

Pause control and reduced motion

Standard WCAG 2.2 success criterion 2.2.2, Pause, Stop, Hide, is Level A, the lowest level. It says: "For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it". A hero loop starts by itself, runs beside the headline, and usually loops for longer than five seconds in total, so it needs a visible pause button. W3C explains the five seconds: it "was chosen because it is long enough to get a user's attention, but not so long that a user cannot wait out the distraction if necessary to use the page."

Recommended Visitors can also ask their device for less motion. MDN: "The prefers-reduced-motion CSS media feature is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion." A hero loop is non-essential motion, so when the setting is on, show the poster and do not start the video. On our own site, nothing autoplays when it is set.

When autoplay does not happen

Browser rule A muted video is allowed to autoplay, but that is not a promise that it will. Chrome's article says it twice: "Don't assume a video will play, and don't show a pause button when the video is not actually playing." Its advice is to check the promise that play() returns, and to show a play button if it is rejected. MDN's autoplay guide describes the same check, looking for a NotAllowedError.

WebKit adds that autoplaying video on iOS waits until it can be seen: such elements "will only begin playing when visible on-screen such as when they are scrolled into the viewport, made visible through CSS, and inserted into the DOM." Our own loops are started from a script when they are on screen and paused when they leave it, so a page with several loops only plays the ones in view.

Where other guides differ

The pages that rank for this search are help pages from website builders and university web teams. We read two of them on 28 October 2026:

• The pause control. A university web standard asks for hero videos edited to under 10 seconds, which loop. Neither page mentions a way to pause, though WCAG asks for one when moving content lasts more than five seconds.
• iPhone. Neither mentions playsinline, without which an iPhone does not play the video inline.
• File size. One sets a maximum upload of 75 MB, about 100 times our 0.77 MB loop; the other asks for under 5 MB. Our six second loops are well under the second.
• Reduced motion. Neither mentions it.

Both recommend MP4 at 720p, and one names H.264, which matches our own files.

The checklist

Making the loop

• Build the end to meet the start, so the repeat does not jump.
• Keep text out of the video: put the headline in the page, where it is sharp and readable by search engines.
• Export 1280 x 720, no audio track, WebM and MP4, plus a poster of the first frame.

On the page

• autoplay muted loop playsinline, a poster, width and height.
• WebM source first, MP4 second.
• A visible pause button if it plays for more than five seconds.
• No autoplay under prefers-reduced-motion.
• Check the play() promise and show a play button if it fails.

Before it goes live

• Test on a real iPhone and a real Android phone, not only a desktop browser.
• Check the page's first screen weight on a phone.

Sources

Every page below was read in full on 28 October 2026. The dates in brackets are the pages' own.

• Chrome Chrome for Developers, Autoplay policy in Chrome (last updated 13 September 2017)
• WebKit WebKit blog, New video policies for iOS (25 July 2016)
• MDN The Video Embed element (last modified 16 July 2026) and Autoplay guide for media and Web Audio APIs (last modified 10 September 2026)
• MDN prefers-reduced-motion
• web.dev Video performance (last updated 2 April 2026) and Lazy loading video (last updated 2 July 2026)
• W3C Understanding Success Criterion 2.2.2: Pause, Stop, Hide
• Our measurement The two loop files named above, read with ffprobe, and the three commands above, run on 28 October 2026