ads.txt and sellers.json explained: the files that authorize the supply chain

Two of the most important files in advertising are plain text you could open in Notepad. ads.txt and sellers.json don’t sound glamorous, but they’re the mechanism that turned the programmatic supply chain from an opaque black box into something a buyer can actually verify. If you want to understand why fraud got harder and transparency got real, start here.

Here’s what each file does and how they fit together.

The problem they solve

In open programmatic, a buyer receives a bid request claiming to sell an impression on publisher.com. But historically the buyer had no way to check that claim. Fraudsters exploited exactly this — domain spoofing, where junk inventory is passed off as a premium site, and unauthorized reselling, where middlemen sell inventory they were never allowed to. The buyer paid premium prices for counterfeit supply.

ads.txt and sellers.json are the industry’s answer: a way to publicly declare, and independently verify, who is authorized to sell what.

ads.txt — who’s authorized to sell my inventory

ads.txt (Authorized Digital Sellers) is a file a publisher hosts at the root of its domain (publisher.com/ads.txt). It publicly lists every advertising system authorized to sell that publisher’s inventory, and the publisher’s seller account ID in each.

A buyer (or their DSP) can fetch that file and check: is the exchange offering me this impression actually on the publisher’s authorized list? If not, the impression is unauthorized — a red flag for spoofing or unauthorized reselling. Because the file is public and controlled by the publisher, it’s a claim the buyer can trust.

app-ads.txt is the identical concept for mobile apps and CTV, adapted so the file can be discovered from an app’s store listing rather than a web domain.

sellers.json — who is the seller, really

ads.txt says a given exchange is authorized. But who’s the actual entity behind the seller account? That’s sellers.json, a file hosted by the advertising system (the SSP/exchange) that publicly identifies the sellers and intermediaries it works with — their names, domains, and whether each is a direct publisher or an intermediary reseller.

So the two files answer complementary questions:

• ads.txt (hosted by the publisher) → which systems may sell my inventory?
• sellers.json (hosted by the exchange) → who is the entity behind each seller account?

ads.txt authorizes the seller. sellers.json identifies the seller. Together they let a buyer trace a bid request back to a named, authorized source instead of taking it on faith.

The SupplyChain object ties it together

The third piece is the SupplyChain object (schain) carried in the OpenRTB bid request itself. It names every hop the impression passed through, end to end. Cross-referenced against sellers.json entries, it lets a buyer verify the entire path — not just the first seller. (The standard keeps evolving; schain 1.1 extends it to make non-payment intermediaries visible too.)

Together, the three form the transparency stack: ads.txt authorizes, sellers.json identifies, the SupplyChain object proves the path. We went deep on the state of all this in the 2026 supply-chain transparency guide.

Why it matters

These files are load-bearing fraud and quality controls, not paperwork:

• They kill domain spoofing. An unauthorized seller can’t fake its way onto a publisher’s ads.txt.
• They enable supply path optimization. Buyers concentrate spend on clean, authorized, short paths and prune the rest.
• They protect publishers. A clean, current ads.txt and sellers.json presence is how a publisher signals it’s the legitimate, direct source — and avoids being the murky path a buyer cuts.

The catch: they only work if they’re maintained. A stale ads.txt with unauthorized entries, or missing sellers.json records, reintroduces exactly the ambiguity the files were meant to remove.

The takeaway

ads.txt and sellers.json are plain-text files that make the programmatic supply chain verifiable: the publisher’s ads.txt declares who’s authorized to sell its inventory, and the exchange’s sellers.json identifies who each seller actually is. Combined with the SupplyChain object, they let a buyer trace any bid request back to a named, authorized source — the foundation of fraud prevention and supply-chain transparency. Simple files, enormous impact — as long as they’re kept clean.

---

Lumorrow verifies supply-path authorization and provenance on every bid request in real time, pre-auction — turning these files into live decisions, not periodic audits. See how the platform works → or explore it for demand partners →.