vastlint vs SpringServe VAST Tag Tester

Short answer

SpringServe's tag tester at tools.springserve.com/tagtest is a fast way to load a VAST or VMAP tag into a player-style page and watch what happens: which tags were tested, which events fired, how the request flow diagrams out, and what metadata came back. If your question is “does this tag do something in a player right now”, it is a perfectly reasonable spot check.

vastlint answers a different and earlier question: is this tag structurally compliant with the published IAB VAST specifications? It validates VAST 2.0 through 4.3 against public, spec-derived rules, splits the job into a validator for resolved XML, a tester for live URLs, and a wrapper-chain inspector, and ships the same rule engine as a CLI, library, and MCP server you can put in CI.

For most debugging sessions the order matters more than the tool choice. Validate the XML against the standards first, then watch player behavior. Playback symptoms on top of structurally invalid XML are mostly noise.

The fastest way to choose between them

• Use SpringServe tagtest when you want a quick player-style event check with a visual diagram of the request flow.
• Use SpringServe tagtest when the input is a VMAP document and you want to watch the break structure play out. vastlint's VMAP validation is on the public roadmap but has not shipped yet.
• Use vastlint when you need to know whether the tag is compliant with a specific VAST version, with a rule ID, severity, and spec reference for every issue.
• Use vastlint when the failure is somewhere inside a wrapper chain and you need hop-by-hop inspection instead of a single end-to-end result.
• Use vastlint when validation has to run outside a browser session: CLI, CI, server-side pipelines, or an AI agent calling the MCP server.
• Use both when the campaign is valuable: standards validation first, player-style behavior check second.

What SpringServe's tag tester shows on its public surface

The public tool accepts VAST and VMAP input and reports a player view, the tags tested, the events that fired, a request-flow diagram, and tag metadata. That is genuinely useful for operational spot checks, especially when you want to see event firing without wiring up a test page yourself, and it is a natural fit for teams already working inside the SpringServe ecosystem.

What the public page does not surface is the standards layer. No VAST version support matrix is published, there are no public rule-by-rule diagnostics, no documented methodology for what is checked and why, and no public path to embed the checks in your own pipeline. None of that means the tool is bad. It means the public surface is a tester, not a validation product.

Where vastlint closes the gap

• Public rule docs: every rule has its own page with the rule ID, why it fires, and a copyable XML fix.
• Published methodology: rules are derived from IAB XSD schemas where they exist and RFC 2119 normative prose where they do not, including VAST 4.3, which has no published XSD.
• Current version coverage: VAST 2.0, 3.0, 4.0, 4.1, 4.2, and 4.3 are all validated, with automatic version detection.
• Three separated surfaces: a validator for resolved XML, a tester for live URL fetches with creative preview and tracking visibility, and an inspector that unwraps wrapper chains hop by hop.
• Reusable engine: the same Rust core ships as a CLI, Go and npm packages, a VS Code extension, and an MCP server, so the check that ran in the browser also runs in CI and server-side systems.

When vastlint is the better first choice

• The tag fails somewhere and you need the exact element, attribute, and spec reference rather than a playback symptom.
• You are trafficking VAST 4.3 or need consistent checks across all six VAST versions.
• Validation has to be repeatable: pre-commit, CI, or inline in an SSP, DSP, or ad-server pipeline.
• The chain involves multiple wrappers and you need to see which hop breaks.
• An AI agent or automated workflow needs a structured pass/fail with rule IDs, via the MCP server.

When SpringServe tagtest still earns a spot

If your demand or supply partner runs SpringServe, testing in the same environment they use is a legitimate final check. The event view and request-flow diagram are quick to read, and the VMAP support covers a format vastlint does not validate yet.

The mistake to avoid is treating a player-style pass as proof of standards compliance. A tag can play in one tester and still carry structural issues that fail in stricter players, CTV SDKs, or SSAI environments. Run the standards layer first and the player layer second.