What is ads.txt, and how does a buyer read one line?
Part of Supply path transparency
The short answer
ads.txt is a plain text file a publisher posts at the root of its website, such as example.com/ads.txt, naming every company authorized to sell its ad space. Each line gives an ad system's domain, the publisher's account ID in that system, and whether the account is DIRECT or RESELLER. Buyers use it to refuse inventory from unlisted sellers.
Key takeaways
- ads.txt was created in 2017 to fight counterfeit inventory, where a seller offers a website it has no right to sell.
- One line authorizes one account on one advertising system, and that account ID must match the value sent in bid requests.
- How the server answers matters: a 404, a long redirect chain and a placeholder line each mean something different.
- Variables such as SUBDOMAIN and INVENTORYPARTNERDOMAIN change which file governs a given impression.
- An authorized line proves permission to sell, not the quality of the site, so ads.txt is the first check on a site and never the last.
Why was ads.txt created, and what problem does it solve?
The name stands for Authorized Digital Sellers. The change log of the ads.txt 1.1 specification (opens in a new tab) dates version 1.0 to June 27, 2017, and the specification explains the target: inventory offered to buyers with a misrepresented label during real time bidding, typically where the domain of the webpage or the ID of an app has been falsified to look like one the seller has no authorization to sell. That practice is called domain spoofing.
Definition
- ads.txt (Authorized Digital Sellers)
- A public text file at the root of a website that lists the advertising systems and account IDs the publisher authorizes to sell its inventory, and whether the publisher controls each account itself or has handed it to a reseller.
The design borrows from robots.txt. Because the file sits on the publisher's own web server, the specification argues, its presence there proves the website authored it. No registry or sign up is involved: anyone can open a site's file in a browser. Buying platforms read these files at scale. Google's Display & Video 360 help (opens in a new tab), for example, says the platform excludes unauthorized sellers for web, mobile app and connected TV inventory and checks every seller named in the bid request's SupplyChain object against the publisher's file.
How does a buyer read one line of an ads.txt file?
Take a fictional line: greenexchange.example, 48213, DIRECT, 7c1d2e9f. It is a comma separated record with three required fields and one optional field. Read it as a sentence: on the system greenexchange.example, account 48213 may sell this site, the publisher controls that account itself, and the system's certification ID is 7c1d2e9f. The specification adds details in each field that matter when a line does not seem to match what a buyer sees.
Reading one ads.txt line, left to right
- Check the system domain. The first field is the canonical domain of the SSP, exchange or header wrapper that bidders connect to. It may be an operational domain rather than the parent company's, and when one company runs several distinct exchanges it should be the domain of the connection that sends the bid request.
- Match the account ID. The second field must contain the same value used in transactions. In OpenRTB that is typically publisher.id, so a buyer or platform can compare the ID in a live request with the ID the publisher posted.
- Read the relationship. The third field is DIRECT or RESELLER and should be read without regard to capital letters. DIRECT tends to mean a direct business contract between the publisher and the system; RESELLER means another entity controls the account.
- Treat the fourth field as optional. The certification authority ID, today a TAG ID, is superseded by the identifiers object in sellers.json, and the specification warns this field may be deprecated. Its absence changes nothing about authorization.
Where must ads.txt live, and what do server responses mean?
Publishers should post the file at /ads.txt on their root domain, which the specification defines as the public suffix plus one name, so news.example.co.uk rolls up to example.co.uk. The server should return it with the Content-Type text/plain, and when the same file is available over HTTPS and HTTP, the HTTPS copy should be preferred. What a crawler gets back from that address decides how the site is treated.
| Server response | What the specification says to do | What it means for a buyer |
|---|---|---|
| Success (2xx) as text/plain | Read, parse and use the declarations | The listed accounts are the authorized sellers |
| Redirect within the same root domain | Follow it, even several hops, and treat the result as authoritative | An HTTP to HTTPS redirect stays within the root domain |
| One redirect outside the root domain | Allowed once, to delegate hosting to a third party; a further redirect is an error | A chain of outside redirects should be treated as no usable file |
| Restricted (401) | Seek direct contact with the site for access or clarification | Ask the publisher before buying |
| Not found (404) | Assume no declarations exist and that no system is unauthorized | The file cannot help; the site is not proven bad or good |
| Other error after an earlier success | Keep using the last successfully retrieved data | A brief outage does not wipe out authorization |
| Any Content-Type other than text/plain | Treat as an error and ignore the content | An HTML error page at /ads.txt is not a file |
What do the variable lines in an ads.txt file change?
Besides seller records, a file can hold lines of the form VARIABLE=VALUE, plus comments that start with a # character. Crawlers store variables against the root domain, and the specification recommends placing them at the end of the file for readability without letting crawlers assume they will be there. Some variables only inform; others change which file governs the impression a buyer is bidding on.
| Variable | What it declares | Effect on the buyer's reading |
|---|---|---|
| CONTACT | Human readable contact for the file's owner, such as the ad operations team | Who to ask when a line looks wrong |
| SUBDOMAIN | A subdomain within the root domain that has its own ads.txt | Only the systems in that subdomain's file are authorized on that subdomain |
| INVENTORYPARTNERDOMAIN | The domain of a partner explicitly authorized to monetize some ads in the content, whose own ads.txt applies | Authorization extends one hop to the partner's file; IAB Tech Lab's guide for it covers CTV apps |
| OWNERDOMAIN | The business domain of the entity that owns the site | Ties the site to the owner's PUBLISHER entries in sellers.json |
| MANAGERDOMAIN | A primary or exclusive monetization partner, optionally per country | Identifies a sales house that may be the most direct path in that market |
The subdomain rule is easy to misread. When the root file declares a subdomain and that subdomain has a file, only the subdomain's list counts there. When the root file does not declare it, or no file exists on the subdomain, the root list governs. A buyer who opens shop.example.com/ads.txt directly may therefore read a file that crawlers ignore.
What does an ads.txt review look like on a real plan?
Fictional example
A pet supply retailer in northern New England
A fictional pet supply retailer with stores in Maine, New Hampshire and Vermont asks its agency for a display plan beside dog training advice, pet adoption stories and local community news. Before the deal is built, the planner opens the ads.txt file of each of the 18 candidate sites and records what the server returns.
A Vermont dog training blog returns a clean text file with two DIRECT lines and one RESELLER line, all on systems the trading desk buys through. A regional adoption news site serves its file through one redirect to its hosting company's domain, which the specification allows, so its lines count. A Maine community news site returns its homepage as HTML at /ads.txt; the planner logs that as no usable file and writes to the publisher's ad operations team instead of dropping the site.
One candidate posts only the placeholder record. The publisher has authorized nobody to sell programmatically, so that site moves to a direct conversation with its sales team rather than into the deal.
How does PlacementGraph read ads.txt for each site on a list?
Which ads.txt problems should a buyer flag before a deal?
An authorized line proves permission, not quality. A site built only to resell traffic can publish a flawless file, so a made-for-advertising review still applies. The specification also notes a security limit: files are fetched in separate, possibly unauthenticated HTTP requests, so one server could impersonate another, and it advises owners worried about that to redirect HTTP requests for the file to HTTPS. Within those limits, the file itself can show problems worth a question.
ads.txt flags to raise with the publisher or the trading desk
- The address /ads.txt returns an HTML page, a login screen or a server error instead of plain text.
- The file reaches its final location through more than one redirect outside the site's root domain.
- The account ID the trading desk sees in bid requests does not appear on any line for that system.
- The same system and account ID appear twice with different relationship types.
- A subdomain the plan buys has its own file but is not declared with SUBDOMAIN in the root file.
- The file holds only the placeholder record while the site is being offered in a programmatic deal.
Frequently asked questions
Can anyone open a website's ads.txt file?
Yes. Add /ads.txt to the site's root domain in any browser, for example example.com/ads.txt. The file is public by design and is plain text, so no tool or account is needed to read it. Large lists can be checked with a crawler, but a single site can be checked by hand in seconds.
Who writes a website's ads.txt file?
The publisher does, with lines supplied by each exchange or SSP it works with. The specification suggests that exchanges provide a tool that generates the exact lines and consider crawling publishers' domains to warn them when a file or a declaration is missing.
Does ads.txt show a site's ad formats or prices?
No. A line authorizes an account to sell the site's inventory in general; it says nothing about formats, floor prices or deal terms. The specification lists allowed ad formats among its future directions, but version 1.1 does not cover them. Formats and prices come from the exchange, the deal or the publisher's sales team.
Does a site's ads.txt cover its subdomains?
By default, yes. Crawlers strip subdomains and read the root file, and those systems are authorized across the site. A subdomain with different sellers needs its own file plus a SUBDOMAIN line in the root file pointing to it; only then does the subdomain's list replace the root list there.
Is ads.txt used for mobile apps and connected TV?
Apps use a companion file, app-ads.txt, with the same line format. The developer posts it on the website named in the app's store listing. Streaming apps that share inventory with content owners can also point to a partner's ads.txt with the INVENTORYPARTNERDOMAIN variable.
Sources
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- Authorized Digital Sellers with ads.txt and app-ads.txt (version history) (opens in a new tab)IAB Tech Lab
- app-ads.txt specification (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- Authorized Digital Sellers (opens in a new tab)Google, Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.