The <video> and <source> tags

Putting video files into web pages

Once you've prepared a video file with the right dimensions and encoding, the next step is embedding it in a page. That requires two HTML elements: <video> and <source>. Getting the basics right is only part of the job—several attributes on these tags shape how the video behaves and how much bandwidth it consumes.

Declaring a single source

You can technically use <video> alone with a single file, though it's not the recommended approach. If you do, always include the type attribute:

<video src="chrome.webm" type="video/webm">
    <p>Your browser cannot play the provided video file.</p>
</video>

The browser uses type to decide whether it can play the file. If it can't, the text nested inside the <video> element is displayed instead.

Offering multiple formats

Browser support for video codecs varies, so <source> lets you list several file formats as fallbacks. The browser picks the first one it can play:

<video controls>
  <source src="chrome.webm" type="video/webm">
  <source src="chrome.mp4" type="video/mp4">
  <p>Your browser cannot play the provided video file.</p>
</video>

Even though type is optional on <source>, you should always include it. This ensures the browser only downloads a file it is actually capable of playing, rather than fetching data it would have to discard. That matters most on mobile, where bandwidth and latency are limited and patience is short.

Using multiple <source> elements beats server-side format detection in several ways:

• You control format preference by listing order.
• Switching happens client-side with a single request, reducing latency.
• Browser-side selection is simpler and more reliable than user-agent sniffing.
• With type declared, the browser avoids downloading part of a video just to probe its format.

For deeper background on how web video works, A Digital Media Primer for Geeks is a solid resource. You can also use remote debugging in DevTools to compare network activity between pages with and without the type attribute.

Trimming playback with media fragments

You can specify start and end times directly in the video URL to avoid encoding and serving multiple versions of the same clip:

Append #t=[start_time][,end_time] to the media URL. For example, to play from second 5 to second 10:

<source src="chrome.webm#t=5,10" type="video/webm">

Times can also be given in <hours>:<minutes>:<seconds> form. So #t=00:01:05 starts playback at one minute and five seconds, and #t=,00:01:00 plays only the first minute. This feature works like DVD cue points—multiple entry points into one file.

Media fragments depend on range requests, which most servers enable by default but some hosting services disable. Check the Accept-Ranges header in your browser's network panel; it must read bytes for fragments to work. If not, contact your hosting provider.

Showing a poster image

A poster attribute on the <video> element gives viewers a preview of the content before playback starts, without requiring a video download:

<video poster="poster.jpg" ...>
  …
</video>

The poster also acts as a fallback if the src is broken or no listed format is supported. The cost is one extra file request. For sizing guidance, see Efficiently encode images.

Without a fallback poster, a broken video looks like an empty, broken element:

With one, the page still looks as though the first frame has been captured:

Keeping videos in bounds

Video elements wider than the viewport overflow their container, hiding content and making controls unreachable. Simple CSS often fixes this—max-width: 100% is the key rule:

For videos embedded in iframes—YouTube embeds, for example—you can use the responsive approach proposed by John Surdakowski rather than heavier JavaScript libraries like FitVids, which add network payload and can cut into revenue on metered connections.

CSS for responsive embeds

.video-container {
    position: relative;
    padding-bottom: 56.25%;
    padding-top: 0;
    height: 0;
    overflow: hidden;
}

.video-container iframe,
.video-container object,
.video-container embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}

HTML for responsive embeds

<div class="video-container">
  <iframe
    src="//www.youtube.com/embed/l-BA9Ee2XuM"
    frameborder="0"
    width="560"
    height="315"
  ></iframe>
</div>

Compare the responsive version with the unresponsive one to see the difference.

Handling device orientation

Orientation is a non-issue on desktops but critical on phones and tablets. Safari on iPhone switches portrait and landscape smoothly:

iPad Safari and Chrome on Android can behave poorly without customization—an unmodified landscape video on iPad can end up rotated or clipped:

Setting width: 100% or max-width: 100% on the video element resolves most of these layout problems.

Controlling autoplay

The autoplay attribute dictates whether the browser starts playback immediately. Whether it works at all depends on the browser and context:

• Chrome: Behavior depends on factors like desktop versus mobile, and whether the user has the site on their homescreen. See Autoplay best practices.
• Firefox: Blocks all video and audio autoplay, with per-site user overrides. See the Firefox support doc.
• Safari: Has historically required a user gesture, though recent versions have relaxed this. See New <video> Policies for iOS.

Even where autoplay is permitted, weigh whether it's a good idea. Autoplaying media consumes bandwidth and CPU, delays rendering of the page, and can be intrusive in the wrong context.

Preloading content

The preload attribute hints to the browser how much of the video to fetch before playback:

Platforms interpret this differently. Chrome, for example, buffers about 25 seconds on desktop but none on iOS or Android, which can lead to startup delays on mobile. For details, see Fast playback with audio and video preload or Steve Souders' analysis.

With playback controls in place, the next step is making your video accessible by adding captions.