What Is VAST? Video Ad Serving Template Explained

If you have ever tried to run an ad inside a video player and ended up staring at a wall of XML, error codes, and a player that shows no ad and earns no revenue, you have met VAST. Short for Video Ad Serving Template, VAST is the standard that sits behind almost every video ad you have ever seen — the quiet piece of plumbing that lets an ad server and a video player talk to each other. Understanding what VAST is, what a VAST tag actually contains, and how the request-and-response flow works is the difference between ads that load, track, and pay, and ads that silently fail.

This guide explains VAST in plain language, walks through what is really inside a VAST response, and — the part most explanations skip — shows how VAST fits into the streaming delivery path that puts the ad inside your live or on-demand video.

What is VAST, in one sentence

VAST (Video Ad Serving Template) is an XML-based standard, created and maintained by the Interactive Advertising Bureau (IAB), that defines how a video ad is described, delivered, and tracked between an ad server and a video player. First released in 2008, it has become the de facto standard for serving video ads across desktop, mobile, OTT apps, connected TV, and game consoles.

The important idea is that VAST is a common language. Before it existed, every ad server and every player needed custom integration to work together. VAST replaced that chaos with one agreed format: any VAST-compliant player can play an ad from any VAST-compliant ad server, regardless of who built either one. That interoperability is the whole reason the video advertising market could scale.

The single most important thing to understand about VAST

Here is the point that trips up almost everyone new to video ads: a VAST tag is not a video file. It is not a media URL you can drop into a player and expect an ad to appear.

A VAST tag is a set of instructions. Specifically, it is a URL that, when called, returns an XML document. That document tells the player everything it needs to know: where to fetch the actual ad video, how long the ad runs, what type it is, and which addresses to notify when the ad starts, reaches milestones, and finishes. The real video file — usually an MP4 or a streaming URL — is nested deep inside that XML response.

Think of a VAST tag like a restaurant order ticket rather than the meal itself. The ticket does not feed anyone; it carries the instructions the kitchen needs to produce and deliver the right dish. If you tried to eat the ticket, you would go hungry — which is exactly what happens when a developer treats a VAST tag as if it were a video URL: an empty player and no ad revenue.

What is actually inside a VAST response

When a player calls a VAST tag, the ad server responds with an XML document. XML (Extensible Markup Language) is simply a structured, tag-based way of organizing data so that both humans and machines can read it. Inside a VAST response, a few elements do the heavy lifting.

The MediaFile is the actual ad creative — the URL of the video the player will fetch and play. A single VAST response often lists several MediaFiles at different resolutions and bitrates so the player can pick the best fit for the viewer’s device and connection.

The Impression is a tracking URL fired the moment the ad begins rendering. This is one of the most important signals in the entire pipeline, because it is what tells advertisers the ad was actually shown — and, in most commercial arrangements, it is what gets counted for payment.

The TrackingEvents are a set of URLs fired at specific playback moments: when the ad starts, reaches the first quartile, hits the midpoint, reaches the third quartile, and completes. If these do not fire correctly, engagement is under-reported and revenue can quietly leak away.

There are also elements for the Duration of the ad, ClickThrough URLs that define where a viewer goes if they tap the ad, and Error tracking URLs the player calls when something goes wrong. Together, these elements let every party in the chain measure exactly what happened with each ad.

What a VAST response looks like in practice

It helps to see a stripped-down version. A real VAST response is longer and carries more tracking, but the skeleton looks something like this: an outer VAST element with a version number, an Ad element inside it, and within that an InLine block holding the ad system, the ad title, the impression tracking URL, and a Linear creative that contains the duration, the tracking events, and one or more MediaFile URLs pointing at the actual video.

Reading it from the outside in, the player first sees the VAST version so it knows which rules to apply, then finds the Ad and its InLine content, fires the Impression URL as the ad begins, reads the Duration so it knows how long the break should run, selects the MediaFile whose resolution and bitrate best suit the device, and fires each TrackingEvent URL as playback passes the start, quartile, midpoint, third-quartile, and complete milestones. Every one of those pieces is just text inside the XML — which is why a single missing or malformed tag can quietly break tracking or playback without any obvious error on screen.

VAST versions: why the number matters

VAST is not frozen. It has evolved through several versions, and the one an ad server speaks affects what a player must support. Early versions (2.0, 3.0) established the core request-response and tracking model. VAST 4.0, released in 2016, separated the media files from verification and interactivity code and added a dedicated mezzanine file to better support server-side ad insertion — a direct acknowledgment that streaming, not just browser playback, had become central. Later point releases (4.1, 4.2, 4.3) refined verification, added support for newer ad interactions, and improved handling for connected-TV environments, where the old client-side interactive model simply did not fit.

For a publisher, the practical takeaway is that “supports VAST” is not a single checkbox. It is worth knowing which version your ad server returns and which versions your player or insertion platform can parse, because a mismatch is a common and easily overlooked cause of ads that fail to render.

How the VAST request and response flow works

The basic exchange is straightforward. The video player reaches an ad opportunity and calls the VAST tag URL. The ad server receives the request and responds with a VAST XML document. The player parses that XML, locates a suitable MediaFile, fetches the ad video, plays it, and fires the tracking URLs at the right moments. Content then resumes.

There is one wrinkle worth knowing: wrappers. Sometimes the first ad server does not return the ad directly. Instead it returns a Wrapper response — essentially a redirect that points the player to another ad server. That second server may return the real ad (an InLine response) or yet another wrapper. This chain lets multiple ad-tech parties participate in and measure a single ad, but each redirect adds latency, and a broken or slow link in the wrapper chain is a common reason ads fail to load in time.

Where VAST tags come from

VAST tags are generated by the systems that decide which ad to serve. Most often they come from ad servers such as Google Ad Manager or FreeWheel, which return a VAST URL — usually carrying query parameters for the ad unit, device type, and geography — that the player requests at runtime. Tags also arrive from DSPs and programmatic platforms during real-time bidding, often wrapped with extra tracking and redirect logic. In direct-sold campaigns, a brand or agency may hand over a self-hosted VAST tag, which tends to be simpler but follows the same structure.

If the players, servers, and acronyms in that last paragraph are unfamiliar, our guide to DSP vs SSP vs ad exchange explains who decides which ad wins and where VAST fits in the wider chain. Whatever the source, what the player fetches is always the same kind of thing: a VAST URL that returns an XML document describing the ad creative, its duration, its tracking, and its media file.

Common reasons a VAST ad fails

Because VAST is a chain of parsing, fetching, and firing steps, there are several well-known points where it breaks. The most common is conceptual: treating the VAST tag as a video URL instead of parsing the XML to find the MediaFile inside. Beyond that, wrapper chains are a frequent culprit—if a redirect points to a server that is slow or unreachable, the ad times out before it can play.

A format mismatch is another: if the VAST response offers no MediaFile in a codec or resolution the player supports, there is nothing to render. Silent revenue loss often traces back to tracking and error URLs that never fire, so impressions go uncounted even when the ad played. VAST also defines standardized error codes precisely so that when something fails, the player can report why—which is why good debugging starts by reading the raw XML response and following the wrapper chain rather than guessing at the player UI.

None of these are exotic. They are the everyday friction of running video ads, and every one of them becomes easier to diagnose once you internalize that VAST is a structured document to be parsed, not a file to be played.

How VAST relates to VMAP and VPAID

VAST rarely works completely alone, and two related standards come up constantly, so it is worth placing them quickly.

VAST describes a single ad — what it is, where to get it, and how to track it. VMAP (Video Multiple Ad Playlist) sits one level up and handles scheduling: it tells the player where the ad breaks go across the video timeline — a pre-roll before the content, mid-rolls at specific timestamps, a post-roll at the end — and each of those breaks then points to a VAST response for the actual ad. In short, VAST is the ad; VMAP is the schedule of when ads play. If you need multiple, timed ad breaks in a longer video, that scheduling is VMAP’s job, and we cover it in depth in a separate guide.

VPAID (Video Player-Ad Interface Definition) was an older standard for interactive ads that could run code inside the player. Because it created performance and security problems, the industry has moved away from it toward newer approaches, and modern VAST versions carry verification and interactivity in safer ways. For most streaming workflows today, you will be working with VAST, often with VMAP on top for scheduling.

Where VAST fits in the streaming delivery path

Most explanations of VAST stop at the player. But for live and on-demand streaming, there is a second half that decides whether the ad appears cleanly inside the video or breaks the viewing experience — and it is the half that matters most for a streaming business.

In a live stream, an ad opportunity is announced inside the stream itself, commonly by SCTE-35 markers that signal the start and end of a commercial break. When a break opens, the streaming platform generates an ad request and receives a VAST response — the same VAST we have been describing. But in premium streaming, the platform does not simply hand that VAST to a client player and hope it renders. Instead, it reads the VAST response on the server, fetches the ad creative, and stitches it directly into the video stream so the viewer sees it as a seamless part of the broadcast. That server-side technique — server-side ad insertion (SSAI) — is how modern OTT and connected-TV advertising avoids the visible loading, buffering, and ad-blocking problems of the old client-side approach.

This is the key insight for anyone monetizing a stream: VAST is the format the ad arrives in, but something still has to place that ad inside your video. The demand side answers “which ad” by returning a VAST response; the delivery side answers “how it gets into the stream” by reading that VAST and inserting the ad. The two are connected by VAST as the common handshake, which is exactly why a publisher can bring their own ad source and still rely on a separate platform to handle the insertion. The same VAST response can also be delivered through server-guided ad insertion (SGAI) when a workflow needs more player-side flexibility.

Where 5centsCDN fits

5centsCDN operates the streaming delivery and insertion layer. Our platform detects the ad break, sends the ad request, reads the VAST response your demand source returns, and stitches the selected ad into your live or on-demand stream — then delivers it worldwide. In practice, you bring the VAST endpoint — your own ad server, a demand partner, or a programmatic source — and our ad insertion technology turns those VAST responses into ads that actually appear inside the stream, cleanly and at scale. For publishers managing several demand sources and rules, our ad manager adds the decisioning and routing layer on top. If you want to see the standard in action at the player level, our VAST ads player support shows how tags are consumed. If you are still choosing a business model, our OTT monetization models guide covers AVOD, FAST, and the rest.

The takeaway is simple. VAST is the universal instruction set for video ads: not the ad itself, but the structured description of where the ad is, how long it runs, and how to measure it. Master that idea — a VAST tag is instructions, not a video — and the rest of video monetization gets much easier to reason about. If you want help turning your VAST endpoint into inserted, delivered ads, get in touch with our team.

Frequently asked questions