How to make a seamless video background for a website

Why background loops show a cut

A loop shows a cut when its last frame does not match its first. The jump is easiest to see on anything that should be continuous, like a slow camera drift, a horizon or light moving on a wall. That makes it a camera problem first, so the fix starts when you generate or shoot the clip.

The first video we made for our first hero asked for a fixed camera, and the generator panned anyway. Its last frame matched its first by only 64%, and it came out at 832×464. We regenerated it.

Step 1: Lock the camera and limit what moves

Ask for no camera movement in so many words, then name the few things allowed to move. This wording gave us a clean 5-second clip at 1280×720:

locked-off static camera, no camera movement, no zoom, no pan.
The woman stands perfectly still; only her hair and the hem of her dress move gently in the breeze.

Generators take motion words literally. In our tests with one video model, “calm” gave an almost frozen clip, while “clearly visible” invented gestures, clouds and ripples and left the ending different from the start. Ask for even movement of a concrete size, forbid the events you do not want in writing, and budget for 2 attempts.

If the tool has a loop option, use it. In Midjourney, typing --loop into the prompt was not enough for us, and the switch in the interface made the difference.

Step 2: Measure the seam instead of watching it

Score the last frame against the first with SSIM, and call the loop clean when that seam reaches at least 95% of the score between two normal frames. Your eye adapts after a few plays, and a number does not.

ffmpeg -i clip.mp4 -frames:v 1 first.png
ffmpeg -i clip.mp4 -vf "select=eq(n\,1)" -frames:v 1 second.png
ffmpeg -sseof -0.05 -i clip.mp4 -frames:v 1 last.png

# The seam, then the normal step. Read the "All:" value of each.
ffmpeg -i last.png -i first.png -lavfi ssim -f null -
ffmpeg -i first.png -i second.png -lavfi ssim -f null -

The comparison has to be relative. A grainy clip scores low on every pair of frames, so a fixed threshold would fail clips that loop perfectly. The clip above scored 0.868 at the seam against 0.850 between frames, which means the join is no bigger than any other step in the video.

Step 3: Repair a clip that fails

Most failures can be repaired without generating again, and the right repair depends on what went wrong.

For very subtle clips, the standard 8-bit blends can leave a visible step in the middle of a crossfade. Mixing at 16 bits made the join look like any other frame in our case.

Step 4: Encode one file per screen

Encode H.264 MP4 with no audio track, once for desktop and once as a vertical crop for phones. The crop should be centred on the subject, because the desktop file scaled down leaves it too small on a phone.

# Desktop
ffmpeg -i clip.mp4 -an -c:v libx264 -preset slow -crf 19 -pix_fmt yuv420p -profile:v high -movflags +faststart hero.mp4

# Phone: 9:16 crop at 540×960
ffmpeg -i clip.mp4 -an -vf "crop=ih*9/16:ih,scale=540:960:flags=lanczos" -c:v libx264 -preset slow -crf 21 -pix_fmt yuv420p -profile:v high -movflags +faststart hero-mobile.mp4

# Poster: the first frame, so nothing jumps when the video starts
ffmpeg -i clip.mp4 -frames:v 1 -q:v 3 hero-poster.jpg

-an removes the audio track, and +faststart moves the file’s index to the front so playback can start before the download ends. The FFmpeg H.264 guide (opens in a new tab) notes that raising the CRF by 6 roughly halves the file, which makes it the first value to adjust. These are the sizes that came out across our catalogue.

Grain is expensive, because it changes on every frame. A 64-second recording with film grain weighed 70 MB at CRF 25. A light denoise (hqdn3d=4:3:12:12) and CRF 30 at 1280×800 brought it to 16 MB with the same average grain level. H.264 also has the widest reach of the common formats, as Can I use (opens in a new tab) shows.

If you’d rather start from a finished loop, our looping video backgrounds went through these same steps.

Step 5: Embed it so it always has something to show

Paint the poster first, start the video from script and handle a blocked autoplay. A visitor should see a finished image at every point, even if the video never plays.

<video id="hero" muted loop playsinline poster="/hero-poster.jpg" width="1920" height="1080"></video>

<script>
  const hero = document.getElementById("hero");
  const phone = matchMedia("(max-width: 767px)").matches;
  const still = matchMedia("(prefers-reduced-motion: reduce)").matches;
  if (!still) {
    hero.src = phone ? "/hero-mobile.mp4" : "/hero.mp4";
    hero.play().catch((error) => {
      if (error.name === "NotAllowedError") showPlayButton();
    });
  }
</script>

Four details matter here:

• Muted video can start by itself. Chrome’s autoplay policy (opens in a new tab) always allows it, and WebKit’s rules for iPhone (opens in a new tab) add playsinline for inline playback.
• Only one error means blocked. play() (opens in a new tab) rejects with NotAllowedError for that case, and other errors mean something else.
• The poster can set your speed score. web.dev (opens in a new tab) counts the poster or the first frame for Largest Contentful Paint, whichever comes first. On the 5-second clip above, ours came to 50 to 85 KB.
• Moving content needs a pause. WCAG 2.2.2 (opens in a new tab) asks for one when movement starts by itself, lasts over 5 seconds and sits beside other content.

A video is one option among three, so read our comparison of video, WebGL and CSS for a hero background before you commit. The animated backgrounds in our catalogue went through these five steps.