Using ads.txt & sellers.json for Ad Intelligence (Practical Guide)

ads.txt and sellers.json are two small, publicly hosted text files that, read together, tell you who is authorized to sell a publisher's ad inventory and who actually owns a given seller ID in the chain. For competitive and supply-chain research, they're one of the few genuinely factual, verifiable data sources in an industry where most claims (spend, reach, "premium inventory") can't be checked. Here's how to actually use them.

What each file contains, in practice#

ads.txt lives at domain.com/ads.txt on any publisher's root domain, and it's a plain-text list of every company authorized to sell that publisher's inventory, one line per relationship. A typical line looks like:

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

That's the exchange or SSP domain, the publisher's account ID with that exchange, whether the relationship is DIRECT (the publisher deals with them directly) or RESELLER (an intermediary is involved), and an optional certification authority ID. sellers.json is the mirror image, hosted by the exchange or SSP at exchange.com/sellers.json, listing every seller account that exchange works with, their name (sometimes), and whether they're a PUBLISHER, an INTERMEDIARY, or BOTH. Cross-reference the two and you can confirm whether a specific ad slot's claimed seller actually has an authorized relationship, or whether something doesn't add up.

Why this matters for competitive and brand-safety research#

The ad supply chain between an advertiser's budget and a publisher's page is rarely a single hop. Ads frequently flow through one or more resold inventory relationships before landing, and each hop is an opportunity for misrepresentation, domain spoofing, or simple confusion about who's really running an ad. ads.txt and sellers.json exist specifically to make that chain auditable:

• Verifying a network's claim. If a native network or DSP claims direct access to a publisher's inventory, that publisher's ads.txt file will list them as DIRECT. If they only show up as a reseller several hops removed, or don't show up at all, that's useful information before you buy.
• Spotting domain spoofing. Fraudulent operations sometimes claim to represent a premium publisher's inventory without any authorization. Checking ads.txt against the actual bid request domain is a standard, free way to catch this.
• Understanding why an ad looks the way it does. When you're tracing how ad spy tools capture native ads, the ads.txt/sellers.json pairing is often the fastest way to confirm which network actually served a given placement, rather than guessing from the widget's visual style alone.
• Auditing your own supply paths. If you're a publisher, your own ads.txt file is also the fastest way to check whether a partner you cut off (or never authorized) is still listed, or whether an integration added lines you didn't expect.

A practical five-step workflow#

1. Pull the publisher's ads.txt. Fetch https://[publisher-domain]/ads.txt directly in a browser or with a simple script. It's plain text, no authentication needed.
2. Find the line for the exchange or network you're investigating. Search for the domain (e.g., taboola.com, outbrain.com, or the relevant SSP) and note the publisher account ID and whether it's marked DIRECT or RESELLER.
3. Pull that exchange's sellers.json. Fetch https://[exchange-domain]/sellers.json and search for the seller ID you found in step 2.
4. Compare the seller name and type. Does the sellers.json entry match the publisher you started with? Is it listed as PUBLISHER (as expected for a direct relationship) or INTERMEDIARY (expected for a reseller chain)?
5. Follow the chain if it's a RESELLER relationship. A RESELLER line means another entity sits between the publisher and the exchange. Ideally that intermediary should carry its own SupplyChain object (schain) data in the bid request, which records every hop for full auditability, though schain data isn't visible from the ads.txt/sellers.json files alone; it requires access to the actual bid stream or a tool that captures it.

Common findings, and what they mean#

Where this fits with ad network identification more broadly#

ads.txt and sellers.json are strongest for verifying supply-side relationships, not for identifying which network actually delivered a specific ad you're looking at as a buyer. For that, you're usually working from the creative's redirect chain, the widget's visual signature, and the tracking pixel domains involved, which is the approach covered in how to identify the ad network behind any ad. Think of ads.txt and sellers.json as the audit trail for supply relationships, and creative/redirect analysis as the audit trail for what an advertiser is actually running.

Tooling notes#

Both file formats are governed by IAB Tech Lab specifications, and the source specs are the definitive reference if you hit an edge case these files don't cover cleanly, like multi-account setups or OWNERDOMAIN fields. For manual spot checks, a browser and a text search are genuinely enough; you don't need paid tooling for occasional verification. Where it gets tedious is doing this at scale across dozens of publishers or tracking changes over time, which is where a platform that already indexes the supply chain across networks saves the repetitive fetch-and-diff work. OpenAdLibrary's ad intelligence index pairs this kind of supply-path context with the actual live creative and traced landing page, so you're not cross-referencing three separate sources by hand for every placement you want to check.

Why this matters more for native than it looks at first#

Native networks resell inventory constantly. A single content recommendation widget slot on a publisher's page might route through the network directly, through a regional reseller, or through a header-bidding wrapper that's brokering several demand sources at once. Because native ads rarely carry the kind of visible branding a display banner does, and because the widget itself often looks identical regardless of which network is actually behind it, ads.txt and sellers.json are sometimes the only reliable way to confirm which network legitimately holds a given publisher relationship, especially when a publisher's site runs multiple native widgets side by side from different providers. This is also why header-bidding setups, where several exchanges compete for the same slot in real time, benefit from the same verification: each participating exchange should have its own authorized line in the publisher's ads.txt, and its own matching sellers.json entry.

Doing this at scale versus doing it once#

Checking one publisher's file by hand takes a couple of minutes. Checking it across a watchlist of fifty publishers, on a recurring basis, to catch new or dropped relationships, is a different problem, and it's the kind of thing that quietly stops happening once the initial curiosity wears off, even though the value comes from doing it repeatedly. If you're building this into a standing research process rather than a one-off check, it's worth pairing it with whatever ad supply chain monitoring you already do for creative and landing-page changes, so the supply-side and creative-side pictures update together instead of drifting out of sync.

A note on limits#

These files are self-declared by publishers and exchanges. Nothing forces a publisher to keep ads.txt current, and a stale or incomplete file is common, especially on smaller sites. Treat a missing or inconsistent entry as a prompt to investigate further, not automatic proof of fraud; plenty of legitimate small publishers simply haven't updated their file recently. The value of ads.txt and sellers.json is that they make the supply chain checkable at all, not that they make it infallible.