Wiki · Concept · Last reviewed June 25, 2026

ads.txt

ads.txt, short for Authorized Digital Sellers, is the IAB Tech Lab standard that lets publishers declare which advertising systems are authorized to sell their digital inventory.

Category: Concept / Ad Tech Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: ads.txt, app-ads.txt, adtech, real-time bidding, supply chain, privacy

Definition

ads.txt is a plain-text transparency standard for programmatic advertising. IAB Tech Lab says the project's mission is to increase transparency in the programmatic advertising ecosystem by letting publishers and distributors publicly declare the companies they authorize to sell their digital inventory. The 1.0.3 specification describes ads.txt as focused on advertising inventory hosted by the website publishing the file.

The standard was developed in 2017 for desktop and mobile web inventory. IAB Tech Lab later released app-ads.txt version 1.0 for software applications distributed through mobile app stores, connected television app stores, and similar channels. The difference matters: a website can host /ads.txt at its own domain, while an app needs a developer website or app-store-linked domain where buyers can find the authorization file.

ads.txt is not a privacy law, consent mechanism, fraud guarantee, or user-facing explanation. It answers a narrow question: which advertising systems does this publisher or distributor say are authorized to sell this inventory?

Mechanism

An ads.txt file is normally published at the root of a publisher domain, such as example.com/ads.txt. Each authorization record names the advertising system domain, the publisher's account identifier within that system, the relationship type, and optionally a certification authority identifier. The relationship field distinguishes direct relationships from reseller relationships using values such as DIRECT and RESELLER.

Buyers, exchanges, supply-side platforms, crawlers, and compliance tools can fetch the file and compare bid requests against the publisher's declared sellers. If a bid request claims to sell inventory for a domain but the selling account is not authorized in that domain's ads.txt file, the buyer can reject it or send it to manual review.

The standard also supports special cases. The 1.0.3 specification describes directives such as subdomain= for subdomain-specific files and inventorypartnerdomain= for certain inventory-partner arrangements. App-ads.txt extends the pattern to app inventory so buyers can verify sellers for mobile and connected-TV applications.

Agent Context

For AI-assisted media buying, brand safety, and ad compliance, ads.txt is a useful machine-readable checkpoint. A buying agent can retrieve the file, compare seller IDs against bidstream evidence, flag unauthorized paths, and preserve the retrieval time and file hash in an audit trail. A publisher-side agent can monitor whether exchange partners are missing, stale, or incorrectly labeled.

The larger lesson is that automated markets need public authorization surfaces. If agents negotiate ad spend, optimize supply paths, or police fraud at machine speed, they need something more reliable than vendor prose. ads.txt gives them a minimal public record to test before money and data move.

Governance Use

A governed deployment should record the ads.txt URL, retrieval time, file hash, publisher domain, app developer domain where relevant, advertising-system domain, seller account ID, relationship type, certification authority ID, crawler version, and policy decision. When app-ads.txt is used, the record should also include the app-store listing or developer website path used to discover the file.

Controls should connect authorization to the rest of the adtech chain. ads.txt can help reject counterfeit inventory, but it should sit beside Sellers.json, SupplyChain Object inspection, bidstream field review, consent logging, retention limits, and vendor contracts. The question is not only whether a seller was authorized, but what data the seller received and what it was allowed to do with it.

Limits

ads.txt is only as good as the published file and the systems that check it. A file can be missing, stale, overbroad, incorrectly formatted, placed on the wrong domain, or populated with resellers the publisher does not understand. Buyers may choose not to enforce it. Fraud can move to channels or representations that the file does not cover.

Most importantly, authorized does not mean benign. An authorized seller can still participate in excessive data broadcast, weak consent flows, discriminatory targeting, manipulative creative testing, or opaque audience enrichment. ads.txt reduces one kind of supply-chain ambiguity; it does not govern the whole surveillance economy around the auction.

Source Discipline

Claims about ads.txt should cite IAB Tech Lab's ads.txt materials and identify the exact variant: web ads.txt, app-ads.txt, sellers.json, or the OpenRTB SupplyChain Object. Claims about privacy, legality, targeting, or data protection require separate evidence. A file proving seller authorization is not proof that the downstream processing was fair, lawful, or understood.

Spiralist Reading

Spiralism reads ads.txt as a small public boundary in a hidden market. It says that even an ad impression has a chain of authority, and that the chain should not be left entirely to private logs. The discipline is modest but useful: name who is allowed to sell the attention before the auction begins.

Sources

Return to Wiki