Pixellint
Pixellint is a spec-first validator for pixels, postbacks, conversion API payloads, and other measurement artifacts. It runs in a terminal, in CI, and in agents, and every finding carries a stable id, a severity, an evidence level, and the document it came from.
Broken pixels cost attribution, QA time, and campaign money. The tooling that exists is fragmented: vendor-specific helpers, enterprise tag auditors, and schema linters that know nothing about ad tech. Pixellint is the open validation layer underneath all of that.
)
))) )
Server-side events are checked in the body, one event at a time:
)
Install
Or paste a URL into the playground at pixellint.org, which runs the same engine in your browser and sends nothing anywhere.
Use it
QA
Validate an inline artifact, a file with @path, or stdin with -:
|
If the artifact is still a template with unexpanded macros, say so, and macro rules adjust:
CI
pixellint validate exits 0 when the artifact is clean or only produced
warnings, 1 when any error-severity finding is present, and 2 on a usage or
input problem. That makes it usable as a gate:
- name: Validate tracking artifacts
run: |
cargo install pixellint
pixellint validate url @fixtures/conversion-pixel.txt
Agents
pixellint-mcp speaks MCP over stdio and exposes three tools:
list_rulepackslist_vendors, optionally filtered bycategoryor attributing a singlehostvalidate_artifact, takingartifact_kind,artifact, and optionalclaimed_vendor,expansion_state,rulepacks,except_rulepacks
Responses include the structured findings, the detected vendors, and a severity summary, so an agent can act on the result without parsing prose.
Node and the browser
import from "pixellint";
const summary = ;
; // false, the pixel id is missing
Library
use ;
let engine = default;
let request = ValidationRequest ;
let summary = engine.validate?;
assert!;
Rulepacks
core runs on every URL-like artifact. Vendor packs run only when the artifact
targets their endpoints, so you get vendor checks without asking for them, and
nothing fires on an endpoint it does not understand. A conversion API body has
no endpoint to go by, so those packs claim it by the shape of the payload.
| Rulepack | Covers | Evidence |
|---|---|---|
core |
URL validity, transport, credentials, fragments, ad-tech macro handling, IAB consent signals | normative |
vendor/meta |
facebook.com/tr pixel requests |
official vendor |
vendor/meta-conversions-api |
Graph API events edge, URL and JSON event payload | official vendor |
vendor/google-analytics |
GA4 Measurement Protocol, URL and JSON event payload | official vendor |
vendor/google-analytics-collect |
The /g/collect transport the Google tag uses in the browser |
ecosystem reference |
vendor/google-tag-manager |
gtm.js, gtag/js, and ns.html loader requests |
official vendor |
vendor/google-ads-conversion |
Google Ads conversion and view-through pixels | official vendor |
vendor/floodlight |
Campaign Manager Floodlight activity tags | official vendor |
vendor/adobe-analytics |
Adobe Analytics data collection beacons | official vendor |
vendor/pinterest |
Pinterest tag requests and the noscript fallback | official vendor |
vendor/snapchat |
Snap Conversions API v3, URL and JSON event payload | official vendor |
vendor/tiktok |
TikTok Pixel loader and collection requests | ecosystem reference |
vendor/linkedin |
LinkedIn conversion image pixels | ecosystem reference |
vendor/linkedin-conversions-api |
LinkedIn conversion events, single and batched | official vendor |
vendor/microsoft-uet |
Microsoft Advertising Universal Event Tracking | ecosystem reference |
vendor/reddit |
Reddit Pixel conversion requests | ecosystem reference |
Vendor directory
Rulepacks cover fifteen endpoint families in depth. The vendor directory covers the rest by attribution: 89 vendors and 217 hosts, so an unrecognized pixel still gets a name.
)
)
Directory entries make one claim, that a host belongs to a vendor. They carry
no parameter contracts, the finding is always info, and attribution never
changes an exit code. See docs/VENDOR_DIRECTORY.md.
Select packs per run:
Full rule inventory with citations: docs/STANDARDS.md.
Evidence levels
Findings say where their authority comes from, and you can hold packs to different standards accordingly:
normative: a formal standard such as the WHATWG URL Standard or an RFCofficial_vendor: a parameter contract the vendor publishes, with the URLofficial_template: vendor-published templates or SDK behaviorecosystem_reference: consistent real-world behavior the vendor generates in its own UI but does not documentheuristic: Pixellint's judgment, labeled as such
The manifest loader refuses to compile a pack that claims official_vendor
without citing documentation.
Custom rulepacks
Rulepacks are data, not code. First-party vendor packs are written in the same JSON format you can write for an internal endpoint:
The format is documented in docs/RULEPACK_SCHEMA.md.
What Pixellint does not do
- It does not extract artifacts from documents. Callers such as Vastlint parse VAST, HTML, or GTM containers and hand Pixellint the URLs they found. The planned document-level result model is in docs/MULTI_ARTIFACT_SCHEMA.md.
- It does not fire requests or check whether an endpoint responds.
- It does not auto-fix. Findings carry fix hints; applying them is on you.
Evidence
Every rule is backed by tests: unit tests in crates/pixellint-core/src/, a
golden corpus in fixtures/ with one directory per rulepack, and integration
tests that drive the real CLI binary and the real MCP stdio transport.
Docs
- Standards and rule inventory
- Vendor directory
- Playground and npm package
- Rulepack manifest schema
- Architecture
- Roadmap
- Multi-artifact output model
License
Apache-2.0. Pixellint is not affiliated with or endorsed by any vendor named in its rulepacks; see NOTICE.