VASTlint
Validate

VAST tag validation in Node.js and TypeScript

Short answer: use the vastlint npm package. It gives you the same validation core used by the CLI and web validator, but inside Node.js, TypeScript, browser QA tools, and React workbenches.

This is the right choice when validation needs to run inside your own codebase instead of a manual browser flow. Use the hosted validator for one-off XML checks, the tester for live VAST tag URLs, and the inspector for wrapper-chain debugging.

Why use the npm package

  • Runs inside Node.js, TypeScript services, browser tools, and React QA UIs
  • Uses the same rule engine as the web validator and CLI
  • Good fit for CI, content QA, CMS validation, and custom ad-ops tools
  • Lets you keep validation local instead of shipping XML to a remote service

Install

npm install vastlint

Minimal example

import { validate } from "vastlint";

const result = validate(vastXml);

if (result.summary.errors > 0) {
  for (const issue of result.issues) {
    console.error("[" + issue.severity + "] " + issue.id + ": " + issue.message);
  }
}

Why validate VAST in-process

A malformed VAST tag is a billed impression that never renders: the player loads, the auction clears, the publisher is charged, and the viewer sees nothing. Because the failure surfaces in the player, not your logs, it is easy to ship a broken tag and never connect the revenue dip to the cause.

Posting every tag to a remote validation API adds a network hop, a rate limit, and a dependency to a path that should be cheap and local. The vastlint package is the same Rust engine compiled to WASM and called in-process, so validation is a synchronous function call with no service to stand up, no XML leaving your process, and the same result whether it runs in a request handler, a Lambda, or a build step.

Where it lands in an SSP, DSP, or ad server

In a Node.js stack, validation usually belongs at the points where a creative enters or leaves your control: ingestion, a serverless preflight endpoint, or the ad-ops tools your team uses to traffic and review tags.

  • Trafficking and CMS: validate tags at the moment they are pasted or uploaded, so bad creatives are caught in the trafficking UI rather than in production.
  • Serverless preflight: a small validation endpoint (Lambda, Cloud Function, route handler) that demand partners or internal tools call before a tag is approved.
  • SSP / DSP tooling: a Node service that validates seatbid.bid.adm samples from demand partners and reports error rates per seat for SLA enforcement.
  • Ad-ops dashboards: back a creative-QA console with the same engine the rest of the pipeline uses, so the report a trafficker sees matches what the bidder enforces.

For the front-end half of those tools, the same package runs in the browser; see the browser, WASM, and edge guide and the React hooks.

When not to use the npm package

If you already have raw XML in front of you and just want a quick manual answer, use the web validator. If you only have a live VAST URL, use the tester. If the problem is redirects or depth limits, use the wrapper inspector.

Related reading