Definition
ads.txt — short for Authorized Digital Sellers — is a simple, public text file that publishers place at the root of their domain (at /ads.txt) listing every company authorized to sell their advertising inventory. It’s an IAB Tech Lab standard, introduced in 2017, designed to stamp out domain spoofing and unauthorized reselling in programmatic advertising. The idea is disarmingly low-tech: if a publisher publicly declares who’s allowed to sell its inventory, then any “inventory” offered by a company not on that list is, by definition, unauthorized — and buyers can refuse it.
Before ads.txt, fraudsters could spoof a premium publisher’s domain and sell fake impressions that looked like the real thing, siphoning ad dollars away from legitimate publishers. ads.txt closes that loophole by giving buyers a verifiable list to check against. There’s a companion standard, app-ads.txt, that does the same job for mobile apps and CTV.
Disambiguation: ads.txt is one of three related IAB Tech Lab supply-chain transparency standards, and they answer different questions. ads.txt declares who is authorized to sell a publisher’s inventory (published by the publisher). sellers.json declares who the sellers and intermediaries actually are (published by SSPs and exchanges). SupplyChain Object declares the full path an impression traveled from publisher to buyer (passed in the bid request). Together they let a buyer verify authorization, identity, and route — but each covers a different piece, and ads.txt is specifically the authorization layer.
See also: sellers.json · SupplyChain Object (schain) · Invalid Traffic (IVT) · Supply-Side Platform (SSP)
Why it matters for marketing
ads.txt is one of the most effective anti-fraud tools the programmatic industry has, and for advertisers it’s a first line of defense against wasting budget on counterfeit inventory. Domain spoofing — passing off worthless inventory as impressions on a premium site — used to drain meaningful sums from the ecosystem. By checking ads.txt, a buyer’s DSP can confirm that whoever is offering “premium publisher” inventory is genuinely authorized to sell it, and reject the bid if not. Adoption became near-universal for premium publishers precisely because buyers started refusing to purchase unauthorized inventory.
For marketers, the practical value is that ads.txt makes the supply chain auditable at the authorization layer. It supports supply path optimization by revealing which sellers a publisher endorses, and it’s a baseline quality signal — publishers who maintain a clean, accurate ads.txt file are participating in the transparency the ecosystem now expects. It doesn’t solve every fraud problem (sophisticated invalid traffic goes beyond spoofing), but it removed one of the easiest and most lucrative attacks.
How it works
The mechanism is deliberately simple, which is why it works:
- The publisher posts the file. At
example.com/ads.txt, the publisher lists each authorized seller as a line containing the SSP or exchange’s domain, the publisher’s account ID with that seller, the account type (DIRECT if the publisher works with them directly, RESELLER if authorized to resell), and an optional certification ID. - A DIRECT vs. RESELLER distinction. DIRECT means the named company sells the publisher’s inventory directly; RESELLER means the publisher has authorized that company to resell it. This lets buyers see not just who’s authorized, but how directly.
- Buyers crawl and verify. DSPs and verification vendors regularly crawl publishers’ ads.txt files and build a database. When a bid request claims to be a certain publisher’s inventory sold by a certain seller, the buyer checks whether that seller appears in that publisher’s ads.txt. If not, the impression is unauthorized and can be rejected.
- app-ads.txt extends it. For apps and CTV, where there’s no simple web root, app-ads.txt is hosted on the developer’s website (referenced from the app store listing) and works the same way.
How to utilize ads.txt
- Buyers: enforce it. Configure buying to verify ads.txt and reject or down-weight unauthorized inventory. This is the core protective use.
- Assess publisher hygiene. A clean, current ads.txt with sensible DIRECT/RESELLER entries signals a well-run publisher. A bloated file listing hundreds of resellers can be a caution flag.
- Publishers: keep it accurate. Maintaining an up-to-date ads.txt is now table stakes for selling premium inventory. Buyers reject inventory from sellers not listed, so omissions cost real revenue.
- Combine with the other standards. Read ads.txt alongside sellers.json and the SupplyChain Object for a full authorization-identity-path picture rather than authorization alone.
Comparison: the supply-chain transparency standards
| Standard | Question it answers | Published by | Where it lives |
|---|---|---|---|
| ads.txt / app-ads.txt | Who is authorized to sell this inventory? | Publishers | Publisher’s domain root |
| sellers.json | Who are the sellers and intermediaries? | SSPs / exchanges | Seller’s domain |
| SupplyChain Object | What path did this impression travel? | Passed by each hop | In the bid request |
The three are complementary layers of one transparency system. ads.txt is the authorization layer, sellers.json the identity layer, and the SupplyChain Object the routing layer. Used together they make the programmatic path auditable end to end.
Best practices
- Publishers: audit the file regularly. Remove sellers you no longer work with, keep account IDs correct, and don’t let the file bloat with stale reseller entries. Accuracy is the whole value.
- Buyers: verify at scale and act on it. Crawling ads.txt is only useful if you actually reject unauthorized inventory. Enforcement, not just checking, is what protects budget.
- Use DIRECT where possible. For buyers, DIRECT relationships (publisher to seller) are generally cleaner and shorter than long RESELLER chains. Preferring DIRECT paths supports supply path optimization.
- Don’t treat it as complete fraud protection. ads.txt stops domain spoofing and unauthorized reselling, but not all invalid traffic or sophisticated fraud. Pair it with fraud detection and the other standards.
- Support app-ads.txt for in-app and CTV. As spend shifts to apps and streaming, app-ads.txt matters as much as ads.txt does for the web.
Future trends
ads.txt is now mature and near-universally adopted for premium web inventory, and its extension into app-ads.txt has followed the money into mobile and CTV. As programmatic spend continues migrating into streaming, retail media, and other environments, the pressure is on to make authorization verification work cleanly in places that don’t have a simple web domain — an ongoing area of standards work.
The broader direction is toward the three transparency standards operating as an integrated system rather than separate checks. As buyers get more sophisticated about supply path optimization and inventory quality, they increasingly cross-reference ads.txt, sellers.json, and SupplyChain Object together to build a complete, verifiable picture of every impression’s origin and route. ads.txt won’t stop being foundational, but its value increasingly comes from being one verified layer in a fuller transparency stack.
FAQs
What is ads.txt? Authorized Digital Sellers — a public text file publishers post at their domain root listing the companies authorized to sell their ad inventory. It’s an IAB Tech Lab standard for preventing domain spoofing and unauthorized reselling.
What problem does ads.txt solve? Domain spoofing and unauthorized reselling, where fraudsters pass off fake or unauthorized inventory as a premium publisher’s. Publicly declaring authorized sellers lets buyers reject anything from a seller not on the list.
What’s the difference between DIRECT and RESELLER in ads.txt? DIRECT means the listed company sells the publisher’s inventory directly. RESELLER means the publisher has authorized that company to resell its inventory. The distinction shows buyers how directly they’re buying.
What is app-ads.txt? The mobile-app and CTV equivalent of ads.txt. Because apps have no web root, app-ads.txt is hosted on the developer’s website (referenced from the app store listing) and works the same way.
How do advertisers use ads.txt? Their DSPs and verification vendors crawl publishers’ ads.txt files and check whether a bid’s claimed seller is authorized. Unauthorized inventory can then be rejected, protecting budget from spoofed impressions.
Does ads.txt stop all ad fraud? No. It stops domain spoofing and unauthorized reselling, but not all invalid traffic or sophisticated fraud. It should be paired with fraud detection and the other transparency standards.
How does ads.txt relate to sellers.json? They’re complementary. ads.txt (from publishers) declares who’s authorized to sell; sellers.json (from SSPs and exchanges) declares who those sellers actually are. Together they let buyers verify both authorization and identity.
Is ads.txt required? Not legally, but practically yes for premium publishers. Buyers widely reject inventory from sellers not listed in a publisher’s ads.txt, so not maintaining one costs revenue.
Related Terms
- sellers.json
- SupplyChain Object (schain)
- Invalid Traffic (IVT)
- Supply-Side Platform (SSP)
- Supply Path Optimization (SPO)
- Programmatic Advertising
- Ad Exchange
- Brand Safety
- Made for Advertising (MFA)
- Demand-Side Platform (DSP)
Sources
- IAB Tech Lab — ads.txt specification: https://iabtechlab.com/ads-txt/
- IAB Tech Lab — app-ads.txt: https://iabtechlab.com/ads-txt/about-app-ads-txt/
- Digiday — WTF is ads.txt: https://digiday.com/media/wtf-ads-txt/