skip to content

In HTML, what does the poster attribute on `<video>` do, and what do `preload="none"`, `preload="metadata"` and `preload="auto"` tell the browser?

level: juniorimportance: should knowfreq 52%

answer

  1. one attribute is an image, one is a hint
  2. three keywords, increasing appetite
  3. poster is a separate request
  4. none, metadata, auto
  5. the default is implementation-defined

basics

~20 s

poster names an image the browser shows in the video's frame until playback produces a picture. preload is a hint about how much of the media file to fetch before play: none fetches nothing, metadata fetches just duration and dimensions, auto invites the browser to buffer the whole thing.

solid answer

~50 s

`poster` takes an image URL that fills the `<video>` box before playback, so the element is not a black rectangle on first paint — it is a separate image request, and it exists only on `<video>`, never on `<audio>`. `preload` is a hint about the media file itself, with three keywords: `none` says do not touch the resource until the user asks, `metadata` says fetch just enough to learn duration, dimensions and the seekable ranges, and `auto` says the browser may pull the whole file if it thinks that is worthwhile. The HTML specification leaves the default implementation-defined, and browsers routinely override the hint anyway — mobile browsers on a metered connection often behave like `none` whatever you wrote. Treat `preload` as advice, and always pair it with a `poster` so the frame looks intentional before any media arrives.

code

html · 7 lines
html
<!-- Optional long video: fetch nothing up front, but still show a frame -->
<video src="webinar.mp4" controls preload="none"
       poster="webinar-title.jpg" width="1280" height="720"></video>

<!-- The clip the page is about: buffer eagerly -->
<video src="demo.mp4" controls preload="auto"
       poster="demo-frame.jpg" width="960" height="540"></video>

go deeper

for a junior

Know all three preload keywords and be able to say what poster shows and when. Naming none, metadata and auto correctly is most of the answer at this level.

for a middle

Explain that preload is advisory, that the missing-value default is implementation-defined, and that the poster image is a separate request unaffected by the hint.

for a senior

Show you reason about cost: several eager videos on one page compete for bandwidth, mobile browsers ignore the hint on metered connections, and width/height plus poster keep the box stable when nothing has loaded.

for a principal

Set the house rule — which embeds may buffer eagerly, what the poster pipeline produces, and how the team verifies that media requests do not fire before intent, rather than leaving each embed to a per-page judgment call.

## Two separate downloads A `<video>` element can pull two different things off the network: the media resource itself, and — if you asked for one — a poster image. `preload` governs the first, `poster` supplies the second. Confusing them is the usual source of "why is my video downloading megabytes before anyone pressed play". ## poster ```html <video src="tour.mp4" controls poster="tour-frame.jpg" width="1280" height="720"></video> ``` The attribute value is a URL for an image the browser paints into the element's box until video playback has a frame to show. Without it, an unplayed video is typically an empty black box — or, with `preload="none"`, an empty box the browser cannot fill because it has not fetched a single video frame. Things worth knowing about `poster`: - It exists on `<video>` only. `<audio>` has no `poster`; if you want artwork next to an audio player you build that yourself in surrounding markup. - It is an ordinary image request, independent of the `preload` hint. `preload="none" poster="x.jpg"` still fetches `x.jpg`. - The image is decorative chrome for the control, not page content, so it is not an alternative to describing the video in the surrounding text. - It also gives the element a picture at a stage where `preload="none"` guarantees the browser has none, which is exactly why the two attributes are usually written together. ## preload and its three keywords `preload` is an enumerated attribute with three keywords: - **`none`** — "I do not expect the user to need this media." The browser is invited to make no request for the resource at all until playback is initiated. Cheapest option; the cost is a longer wait when the user does press play. - **`metadata`** — "Fetch the header, not the content." Enough bytes to know duration, dimensions, track list and seekable ranges, so the control bar can render a real timeline and the layout knows the intrinsic size. This is the sensible default for a page with a video the user *might* watch. - **`auto`** — "Buffering the whole file ahead of time is acceptable." Note the wording: it is permission, not an order. Use it only when playback is the point of the page. An empty value (`preload=""`) maps to the `auto` state, and an unrecognised value falls back to the invalid-value default. ## It is a hint, and the default is not fixed Two facts candidates routinely get wrong. First, the specification deliberately leaves the missing-value default **implementation-defined**. There is no portable "the default is metadata" answer; desktop browsers commonly behave that way, while mobile browsers frequently behave like `none` to protect a metered connection. So do not rely on the default — state your intent explicitly. Second, `preload` is advisory in both directions. A browser may fetch more than you asked (it knows the file is tiny and already cached) or far less (Data Saver is on, the connection is cellular, the tab is in the background). Nothing about `preload` is a guarantee you can assert in a test. ## The interaction with autoplay `autoplay` overrides the hint. If you write `<video autoplay muted preload="none">`, the browser needs media data to honour the autoplay request, so it fetches anyway. The combination is not an error, it is simply contradictory — drop the `preload` when you are autoplaying. ## Choosing in practice ```html <!-- Long video below the fold that most visitors will not watch --> <video src="webinar.mp4" controls preload="none" poster="webinar-title.jpg" width="1280" height="720"></video> <!-- Short clip that is the reason the page exists --> <video src="demo.mp4" controls preload="auto" poster="demo-frame.jpg" width="960" height="540"></video> ``` A useful default: `preload="metadata"` plus a `poster` for most embedded video, `preload="none"` when the file is large and watching is optional, `auto` only for the hero clip on a page built around it. Multiple videos on one page make `none` almost mandatory — three `auto` videos will happily compete for the same connection. ## Why width and height belong here too Setting `width` and `height` on the element gives the box an intrinsic aspect ratio before anything loads, which matters most under `preload="none"` where the browser has no metadata to learn the dimensions from. The poster fills that reserved box instead of the page jumping when playback finally starts.

  • You set preload="none" but the network panel still shows a request before anyone pressed play. What could that be?
    Most likely the `poster` image, which is a separate request the preload hint does not govern. It can also be the browser overriding the hint — `preload` is advisory, and an engine may still fetch metadata if the resource is small or already cached. Confirm by checking the request's URL and type before concluding the attribute is being ignored.
  • Why is preload="auto" a poor choice on a page with several embedded videos?
    Each element may try to buffer its whole resource, so they compete for bandwidth and connections while the user has expressed interest in none of them. That delays everything else on the page and burns mobile data. Use `none` or `metadata` for secondary videos and reserve `auto` for the single clip the page is built around.

saying these in an interview costs you the question

  • Thinking poster is a fallback for unsupported video
  • Claiming preload="metadata" is the guaranteed default
  • Treating preload as a command rather than a hint
  • Putting poster on an <audio> element
  • Combining preload="none" with autoplay and expecting no fetch

context