What is ads.txt?
ads.txt (Authorized Digital Sellers) is a plain-text file that publishers host at the
root of their domain — for example, example.com/ads.txt — to publicly declare
which companies are authorized to sell their digital advertising inventory. It was created by the
IAB Tech Lab and officially launched in 2017 as a simple, open mechanism
to combat domain spoofing and supply-chain fraud in programmatic advertising.
Before ads.txt existed, fraudulent sellers could claim to represent premium publishers in bid requests with no way for buyers to verify those claims. ads.txt solves this by giving publishers direct authorship over a canonical list of their approved supply partners. Because the file lives on the publisher's actual web server, only someone with legitimate access to that domain can modify it — making it a trusted, tamper-resistant declaration of intent.
As of 2025, ads.txt compliance is required or strongly enforced by virtually every major DSP, including Google DV360, The Trade Desk, Amazon DSP, and Xandr. Publishers without a valid ads.txt file face reduced fill rates, lower CPMs, and in some cases complete exclusion from premium programmatic demand.
IAB Tech Lab Specification
The authoritative ads.txt specification is maintained by IAB Tech Lab at iabtechlab.com/ads-txt/. AdsDB tracks real-world adoption across 41,856+ live publisher domains, providing empirical data on how ads.txt is actually deployed in the wild.
The ads.txt File Format
An ads.txt file is a plain UTF-8 text document served with the MIME type text/plain.
Each non-comment line contains exactly three required fields and
one optional field, separated by commas. Lines beginning with # are
treated as comments and ignored by parsers.
Canonical Example
# ads.txt for example.com
# Format: Ad System Domain, Publisher Account ID, Relationship, Certification Authority ID
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
appnexus.com, 7118, DIRECT, f5ab79cb980f11d1
pubmatic.com, 158193, DIRECT, 5d62403b186f2ace
openx.com, 540338152, RESELLER, 6a698e965929636
rubiconproject.com, 17960, RESELLER, 0bfd66d529a55807
criteo.com, B-062114, RESELLER
# Variable declarations
OWNERDOMAIN=example.com
SUBDOMAIN=ads.example.com
CONTACT=adops@example.comField-by-Field Specification
| Field | Name |
|---|
google.comseller_id that appears in the corresponding sellers.json entry. Case-sensitive alphanumeric string.pub-1234567890123456DIRECT or RESELLER. DIRECT indicates a direct contractual relationship with the publisher; RESELLER indicates authorized resale through an intermediary.DIRECTf08c47fec0942fa0Variable Declarations
In addition to seller authorization lines, ads.txt supports special variable declarations that provide additional context about the publisher's supply chain configuration:
| Variable | Description | Example |
|---|---|---|
OWNERDOMAIN |
Declares the root domain of the content owner when using subdomains or when a CMS manages ads.txt on behalf of multiple sites. Helps crawlers trace the ownership hierarchy. | OWNERDOMAIN=example.com |
SUBDOMAIN |
Indicates that a subdomain also has an ads.txt file that should be consulted. Crawlers should additionally fetch ads.txt from the declared subdomain and merge the results. | SUBDOMAIN=news.example.com |
CONTACT |
An email address or URL for buyers to reach the publisher with questions about the ads.txt file. Not parsed for authorization purposes — informational only. | CONTACT=adops@example.com |
DIRECT vs RESELLER
The relationship type field is arguably the most important field in ads.txt. It tells buyers exactly how the listed seller fits into the publisher's supply chain — and significantly affects bid competition, CPMs, and fraud risk.
DIRECT
A DIRECT entry means the publisher has a direct contractual relationship with the advertising system listed in Field 1. The publisher signed up for an account with that SSP or exchange themselves, accepted their terms of service, and receives payment directly from them. There are no intermediaries between the publisher and the listed ad system.
Why DIRECT commands higher CPMs
DSPs strongly prefer DIRECT inventory because the supply chain is shorter and more auditable. Fewer hops mean fewer technology fees deducted, and the buyer's dollar reaches the publisher more efficiently. Most quality-focused DSPs apply bid multipliers that favor DIRECT inventory over RESELLER inventory from the same publisher, making DIRECT relationships more valuable for publishers.
RESELLER
A RESELLER entry means the publisher has authorized a third party to sell their inventory through the listed ad system. The publisher has a relationship with an intermediary — another SSP, network, or header bidding wrapper — and that intermediary in turn has a relationship with the listed exchange. There is at least one extra hop in the supply chain.
RESELLER entries are entirely legitimate and extremely common. Publishers
use resellers for valid reasons: demand aggregation, regional monetization, specialized ad formats (audio, CTV, native), or because a preferred header bidding wrapper routes demand through multiple exchanges. A high-quality publisher may legitimately have dozens of RESELLER entries alongside a handful of DIRECT entries.Comparison at a Glance
| Attribute | DIRECT | RESELLER |
|---|---|---|
| Contractual relationship | Publisher ↔ Ad System | Publisher ↔ Intermediary ↔ Ad System |
| Supply chain hops | 1 (minimal) | 2 or more |
| Buyer preference | Strongly preferred | Accepted, lower priority |
| Typical CPM impact | Higher | Lower (more fees extracted) |
| sellers.json cross-check | seller_type = PUBLISHER or BOTH |
seller_type = INTERMEDIARY or BOTH |
| Relative fraud risk | Lower (shorter chain) | Slightly higher (more parties) |
How DSPs Use ads.txt
DSP validation is the mechanism that gives ads.txt its fraud-prevention power. Compliant DSPs perform this check on every bid request before deciding whether to participate. Here is the complete validation flow:
① Bid Request Received
A bid request arrives at the DSP via OpenRTB, containing the publisher's domain
(site.domain), the selling SSP's identity (inferred from the supply chain or
app.publisher.domain), and the publisher's seat ID (site.publisher.id).
② Fetch the Publisher's ads.txt
The DSP fetches https://[publisher-domain]/ads.txt. In practice, DSPs crawl
ads.txt files periodically — typically every 24–48 hours — and serve results
from a local cache. Real-time fetching on every bid would be impractical at the scale of
billions of daily requests.
③ Parse & Match the Seller
The DSP searches the ads.txt file for a line where Field 1 (Ad System Domain) matches the SSP's domain and Field 2 (Publisher Account ID) matches the seat ID claimed in the bid request. The domain match is case-insensitive; the account ID match is case-sensitive. Both must match simultaneously.
④ Decision: Bid or Filter
Matching entry found: The seller is authorized. The DSP proceeds to evaluate the bid on price and targeting criteria, optionally applying a preference boost for DIRECT entries.
No matching entry: The seller is unauthorized. The DSP discards the bid request. No bid is placed — the unlisted or fraudulent seller earns nothing.
⑤ (Optional) Cross-Check with sellers.json
Advanced DSPs perform an additional verification step: checking the SSP's sellers.json file to confirm the seat ID maps to a seller of the appropriate type — PUBLISHER for DIRECT entries, INTERMEDIARY for RESELLER entries. This two-way check makes large-scale domain spoofing economically unviable.
Important: "No ads.txt" vs "Empty ads.txt"
A domain returning HTTP 404 for /ads.txt is treated differently
from a domain returning HTTP 200 with an empty body. Per the IAB spec, when no
ads.txt is found, some DSPs still bid — treating absence as "no restriction declared."
An empty ads.txt file, however, explicitly authorizes no sellers. Any bid request
from that domain must be rejected by compliant DSPs. An accidentally emptied ads.txt file can
silently block all programmatic revenue.
ads.txt vs app-ads.txt
When mobile app advertising became a major part of the programmatic ecosystem, the IAB Tech Lab extended the ads.txt concept to mobile and CTV apps with app-ads.txt, published in 2019. While the file format is identical, the hosting location and verification mechanisms differ significantly.
| Attribute | ads.txt | app-ads.txt |
|---|---|---|
| Applies to | Web / desktop domains | Mobile apps, CTV apps, OTT apps |
| File location | domain.com/ads.txt(root of publisher domain) |
developer-site.com/app-ads.txt(developer's registered website) |
| Domain verification | Publisher controls the web domain directly | Developer website must match the app store developer listing |
| IAB specification | ads.txt v1.0 (2017), updated v1.1 (2022) | app-ads.txt v1.0 (2019) |
| File format | Comma-delimited, four fields per line | Identical format — same four fields |
| AdsDB coverage | 40,823 files indexed | 40,823 files indexed |
AdsDB indexes both formats. For the mobile and CTV ecosystem, see the app-ads.txt guide and database. For the exchange-side complement that completes the two-way verification model, see the sellers.json guide and database.
Download the AdsDB ads.txt Dataset
The complete AdsDB dataset is available on GitHub under the MIT License — free to use for any purpose, including commercial projects, research, compliance tools, and fraud detection pipelines. No registration, no API key, no rate limits.
📦 Free Dataset — MIT Licensed
Over 40,823 ads.txt files from real publisher domains, organized alphabetically in a predictable directory structure. Clone once, pull daily for continuous updates.
Repository Directory Structure
Files are organized alphabetically by the first character of each domain name, making it easy to enumerate programmatically or navigate by hand:
adsdb/
└── db/
├── a/
│ ├── abc.com/
│ │ └── ads.txt # raw ads.txt file content
│ ├── allure.com/
│ │ └── ads.txt
│ └── anzu.io/
│ └── ads.txt
├── b/
│ └── bbc.com/
│ └── ads.txt
└── ... # a–z plus 0–9Programmatic Access
Fetch individual files directly from GitHub's raw CDN, or clone the entire dataset:
# Fetch ads.txt for a specific domain
curl https://raw.githubusercontent.com/KONTRUSTMEDIA/adsdb/main/db/a/allure.com/ads.txt
# Clone the full dataset (~3.1 GB)
git clone https://github.com/KONTRUSTMEDIA/adsdb.git
# Pull the latest updates (run daily via cron)
git -C ./adsdb pull origin main✅ MIT License — Use for Anything
AdsDB is ideal for building ads.txt compliance checkers, competitive intelligence tools, SSP auditing pipelines, supply-chain visualization dashboards, and academic research into the structure of the programmatic advertising ecosystem. No attribution required (but appreciated).
Browse Notable Publisher Domains
Explore real ads.txt implementations from well-known publishers in the AdsDB dataset. Each domain page shows the complete file contents, a breakdown of DIRECT vs RESELLER entries, and cross-references to sellers.json data where available.
Frequently Asked Questions
Q What is ads.txt?
ads.txt (Authorized Digital Sellers) is an IAB Tech Lab standard introduced
in 2017 that allows publishers to publicly declare which companies are authorized to sell their
digital advertising inventory. Publishers host a plain-text file at the root of their domain
(e.g., example.com/ads.txt), listing all authorized SSPs, ad exchanges, and
resellers. DSPs fetch and parse this file to verify that sellers sending bid requests are
actually authorized by the publisher.
Q Is ads.txt mandatory?
ads.txt is not legally mandated, but it is effectively required for full programmatic monetization. Major DSPs including Google DV360, The Trade Desk, and Amazon DSP heavily filter or discount inventory from publishers without a valid ads.txt file. In practice, publishers without ads.txt lose access to premium programmatic demand, resulting in significantly lower fill rates and CPMs. The MRC (Media Rating Council) also considers ads.txt compliance a baseline requirement for accreditation.
Q How do I create an ads.txt file?
Creating an ads.txt file is straightforward:
1. Create a plain-text file named ads.txt (
2. Contact each SSP, exchange, or ad network you work with and ask for your Publisher Account ID and their canonical Ad System Domain.
3. Add one line per authorized seller in the format:
AdSystemDomain, PublisherAccountID, DIRECT|RESELLER, CertificationAuthorityID4. Upload to the web root of your domain so it's accessible at
https://yourdomain.com/ads.txt.5. Verify it's publicly accessible and correctly formatted.
Your SSPs will typically provide the exact lines to add. Google AdSense and Ad Manager also have built-in tools that auto-generate correct ads.txt lines for your account.
Q What happens if ads.txt is missing?
If a domain returns HTTP 404 for /ads.txt, the IAB spec allows
compliant DSPs to still bid — treating the absence as "no restriction declared." However,
many DSPs apply negative quality signals or bid dampening for domains without ads.txt.
If a domain has an ads.txt file but a seller is not listed in it, compliant DSPs must not purchase inventory from that unlisted seller. The most dangerous scenario is an accidentally emptied or malformed ads.txt file: it can block all programmatic revenue while returning HTTP 200, making the problem hard to detect without active monitoring.
Q What is DIRECT vs RESELLER in ads.txt?
DIRECT means the publisher has a direct contractual relationship with the ad system listed — no intermediary. The publisher signed up for that SSP or exchange themselves and receives payment directly from them.
RESELLER means the publisher authorized another entity to resell their inventory through the listed ad system — there is at least one intermediary. Both are legitimate, but DIRECT commands higher CPMs: shorter supply chains mean lower fees and higher buyer confidence. Publishers typically have fewer DIRECT entries (one per SSP they directly work with) and many RESELLER entries.
Q How does ads.txt prevent ad fraud?
ads.txt's primary target is domain spoofing — a fraud technique where a fraudulent seller claims to be selling inventory from a premium publisher to extract inflated CPMs. Before ads.txt, DSPs had no way to verify whether "New York Times inventory" offered by some obscure SSP was real.
ads.txt solves this by giving publishers direct authorship over a whitelist of approved sellers.
Because the file lives on the publisher's actual server (which they control), only someone with
legitimate server access can modify it. A fraudster cannot add themselves to
nytimes.com/ads.txt without access to the NYT's web server. When a DSP receives
a bid request from an unlisted seller claiming premium inventory, it rejects the bid
immediately — making domain spoofing economically unviable at scale.