ads.txt Explained: 2026 Publisher & Advertiser Guide

ads.txt is a plain-text file that publishers host at the root of their domain (example.com/ads.txt) to declare which sellers are authorized to sell their advertising inventory. The IAB Tech Lab launched the standard in May 2017 to combat domain spoofing, a programmatic-fraud technique where low-quality or counterfeit sites claim to be premium publishers in bid requests. Today, ads.txt is universal among top web publishers, with industry estimates putting adoption at over 95% of Comscore-1000 sites. ^[1]

This guide explains the spec line by line, shows a real annotated example, covers app-ads.txt and sellers.json, walks through setup and validation, and connects ads.txt to the broader click fraud protection landscape.

What is ads.txt and why was it created?

Before ads.txt, programmatic supply paths were opaque. A DSP buying inventory tagged as nytimes.com had no programmatic way to verify the bid actually originated from a seller The New York Times authorized. Bad actors exploited this by spoofing premium domains: a fraud network would label counterfeit inventory as belonging to a top publisher and resell it through second-tier SSPs that did not vet supply paths. Buyers paid premium-publisher rates for traffic that never appeared on the real publisher’s site.

The Association of National Advertisers estimated that domain spoofing and similar supply-chain fraud cost the programmatic industry billions per year before the transparency framework. The ANA’s 2025 Programmatic Transparency Benchmark still puts annual losses at around $26.8 billion despite a decade of progress. ^[2]

The IAB Tech Lab’s response was deliberately simple. Rather than build a centralized registry or new auction logic, they specified a plain-text file at a well-known location that any HTTP client could fetch and any text editor could update. The simplicity is the feature. Adoption did not require new software or industry-wide protocol changes, just a file upload.

The mechanism is straightforward:

1. A publisher lists every authorized seller in https://publisher.com/ads.txt
2. SSPs declare which publishers they represent in https://exchange.com/sellers.json
3. DSPs receive bid requests with seller_id values and check both files before bidding
4. Bid requests where the seller is not listed in the publisher’s ads.txt get rejected

The combined effect: a bid for inventory claiming to be nytimes.com from an SSP NYT never authorized is now visibly fraudulent in the bid stream, and DSPs can refuse it.

The ads.txt spec, line by line

The full IAB Tech Lab specification is publicly available at iabtechlab.com/ads-txt. ^[1] The format is intentionally minimal.

Each line follows this structure:

<seller_domain>, <publisher_account_id>, <account_type>, <TAG_certification_ID>

rubiconproject.com, 12345, DIRECT, 0bfd66d529a55807
└─────── 1 ───────┘ └─2─┘  └─ 3 ─┘ └────── 4 ──────┘

#	Field	Required	What it does
1	Seller domain	yes	SSP canonical domain (e.g., rubiconproject.com)
2	Account ID	yes	Publisher’s account on that SSP, SSP-issued
3	Type	yes	DIRECT, RESELLER, or BOTH, controls trust
4	TAG-ID	optional	TAG certification ID, raises trust score

Lines are comma-separated. One authorized seller per line. Comments start with #.

The four fields:

Position	Field	Required	Description
1	seller_domain	Yes	The canonical domain of the SSP or exchange selling the inventory. Must match the domain used in the bid request seller_id.
2	publisher_account_id	Yes	The publisher’s account ID on that specific SSP. Different SSPs assign different IDs to the same publisher.
3	account_type	Yes	One of DIRECT, RESELLER, or BOTH.
4	TAG_certification_ID	Optional	The publisher’s Trustworthy Accountability Group (TAG) certified TAG-ID, providing additional trust verification.

Account-type values

• DIRECT: the SSP has a direct business relationship with the publisher. The SSP remits payment to the publisher and is responsible for managing the relationship. Most buyers prefer DIRECT-only filtering for clean SupplyChain Object resolution.
• RESELLER: the SSP is authorized to resell inventory through an intermediary chain, but does not have a direct contract with the publisher. Reselling is legal and common, but each additional hop adds opacity.
• BOTH: permitted but rare. Used when the same SSP has both direct and reseller relationships with the same publisher (typically for different inventory categories).

Comments and variables

Lines starting with # are comments and are ignored by parsers. Two control variables are permitted:

# Contact email for ads.txt questions
contact=ads@publisher.com

# Subdomain delegation — separate ads.txt for subdomain
subdomain=mobile.publisher.com

The contact variable is informational. The subdomain variable tells crawlers a specific subdomain has its own ads.txt that overrides the apex file for that subdomain only.

Whitespace and encoding rules

• File must be served with Content-Type: text/plain
• UTF-8 encoding, no BOM (byte-order mark)
• Lines separated by \n (LF) or \r\n (CRLF), both accepted
• Trailing whitespace is ignored but inline whitespace within fields breaks parsing
• The file must be returned with HTTP 200; redirects are followed but introduce parsing risk

An annotated real-world example

Here is what a publisher’s ads.txt typically looks like:

# ads.txt for example.com
# Contact: adops@example.com
# Last updated: 2026-04-15

contact=adops@example.com

# Direct relationships
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
rubiconproject.com, 12345, DIRECT, 0bfd66d529a55807
appnexus.com, 1234, DIRECT
openx.com, 540123456, DIRECT, 6a698e2ec38604c6
pubmatic.com, 123456, DIRECT, 5d62403b186f2ace

# Reseller relationships (via certified partners)
rubiconproject.com, 67890, RESELLER, 0bfd66d529a55807
openx.com, 540987654, RESELLER, 6a698e2ec38604c6
indexexchange.com, 198765, RESELLER

Reading the third line: rubiconproject.com, 12345, DIRECT, 0bfd66d529a55807 means:

• Rubicon Project (now Magnite) is an authorized seller
• The publisher’s account ID at Rubicon is 12345
• It is a DIRECT relationship, Magnite pays the publisher directly
• The TAG-ID 0bfd66d529a55807 is Rubicon’s TAG certification ID

When a DSP receives a bid request claiming to be from this publisher, sourced through Rubicon with seller_id=12345, the DSP can verify:

1. Fetch https://example.com/ads.txt
2. Find the line where seller_domain is rubiconproject.com and publisher_account_id is 12345
3. Confirm the relationship is DIRECT (or accept RESELLER if its policies allow)
4. Cross-check Rubicon’s sellers.json to confirm publisher 12345 corresponds to example.com

If any step fails, the bid is rejected as spoofing.

app-ads.txt: the mobile equivalent

After web ads.txt adoption stabilized, mobile-app fraud became the next domain-spoofing frontier. Counterfeit apps claimed to be premium games or utilities in bid requests. The IAB Tech Lab launched app-ads.txt in March 2019 to extend the framework. ^[3]

The catch: mobile apps do not have URLs the way websites do. You cannot host a file “at the root of the app.” The IAB Tech Lab solved this by anchoring app-ads.txt to the developer’s website URL declared in the app store listing:

1. Developer publishes app to Google Play, App Store, Amazon Appstore, etc.
2. Developer includes a developer website URL in the app store listing (already mandatory in major stores)
3. Developer hosts app-ads.txt at the root of that website
4. SSPs fetch the app’s store listing, extract the developer URL, fetch app-ads.txt from there
5. Same format and validation as web ads.txt

A typical app-ads.txt looks identical to web ads.txt:

# app-ads.txt for ExampleGameStudio
# Developer site: examplegamestudio.com

google.com, pub-9876543210987654, DIRECT, f08c47fec0942fa0
admob.google.com, pub-9876543210987654, DIRECT, f08c47fec0942fa0
applovin.com, abc123def456, DIRECT
unityads.unity3d.com, 1234567, DIRECT

If the same developer publishes both a website and mobile apps, app-ads.txt and ads.txt can be the same file under different names, or fully separate. There is no requirement to combine them.

sellers.json: the supply-side declaration

ads.txt declares which sellers a publisher authorizes. sellers.json declares which publishers a seller represents. The two files are designed to verify each other.

Each SSP or exchange hosts a sellers.json at the root of their domain. The format is JSON (not plain text like ads.txt) because the contents are structured and richer:

{
  "contact_email": "ads@exchange.com",
  "version": "1.0",
  "sellers": [
    {
      "seller_id": "12345",
      "name": "Example Media Inc.",
      "domain": "example.com",
      "seller_type": "PUBLISHER",
      "is_confidential": 0
    },
    {
      "seller_id": "12346",
      "name": "Another Publisher Group",
      "domain": "another.com",
      "seller_type": "PUBLISHER",
      "is_confidential": 0
    },
    {
      "seller_id": "98765",
      "name": "Some Reseller",
      "domain": "reseller.com",
      "seller_type": "INTERMEDIARY",
      "is_confidential": 0
    }
  ]
}

The seller_type field is critical. Values:

• PUBLISHER: the seller_id corresponds to an actual publisher
• INTERMEDIARY: the seller_id corresponds to a reseller or other intermediary
• BOTH: the seller_id can act in either capacity

When is_confidential: 1, the seller name and domain are intentionally hidden. This is permitted by the spec but reduces transparency: buyers may filter out confidential sellers entirely or only buy from them with elevated trust signals (TAG certification, direct contract evidence).

How DSPs use both files together

For each bid in OpenRTB programmatic auctions, a DSP performs the chain of checks:

1. Read bid_request.site.publisher.domain  →  publisher_domain
2. Read bid_request.imp.ext.schain         →  array of seller hops
3. For each seller in the schain:
   a. Fetch <seller>.domain/sellers.json
   b. Find the entry matching seller_id
   c. Validate it points back to publisher_domain
4. Fetch publisher_domain/ads.txt
5. Confirm the top-of-chain seller is listed as an authorized seller

Publisher (example.com)  →  SSP (rubicon/Magnite)  →  DSP (buyer)
  hosts /ads.txt            hosts /sellers.json       verifies bid
  5 declared sellers        account 12345             via schain + both files

DSP verification chain, 3 checks per bid:

1. Fetch publisher.com/ads.txt → find seller_domain + account_id match
2. Fetch ssp.com/sellers.json → confirm account_id maps back to publisher.com
3. Validate SupplyChain Object (schain) in OpenRTB bid request

All 3 pass → bid accepted. Any fail → bid rejected as spoofing.

If any step fails, the bid is fraud-flagged. The SupplyChain Object in OpenRTB makes this verification fast and standardized across exchanges.

How to set up ads.txt: a 10-minute walkthrough

For publishers who do not have ads.txt yet (or who are switching CDNs / hosting), the setup is straightforward:

Step 1: Collect your seller IDs

For each SSP, exchange, ad network, or header-bidding partner you work with:

• Find your publisher account ID in their dashboard (often labeled Publisher ID, Account ID, Network ID, or similar)
• Note their canonical domain (e.g., google.com for AdX, rubiconproject.com for Magnite, pubmatic.com for PubMatic)
• Note the relationship type: DIRECT if you onboarded directly with the SSP, RESELLER if through an intermediary
• Note their TAG-ID if you want to include it (find on each SSP’s documentation)

Step 2: Build the file

Open a text editor (literally any: VS Code, Notepad, vim). Add comments and lines for each seller:

# ads.txt for yoursite.com
# Last updated: YYYY-MM-DD
# Contact: yourname@yoursite.com

contact=yourname@yoursite.com

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0
# ... add lines for each authorized seller

Step 3: Upload to your domain root

Place the file at https://yourdomain.com/ads.txt. Specific deployment varies by stack:

• Static sites / Astro / Next.js: place ads.txt in public/ (or your build’s static-asset directory)
• WordPress: upload via FTP/SFTP to web root, OR use a plugin like Ads.txt Manager
• CDN-fronted sites (Cloudflare, Fastly, etc.): upload to origin, verify CDN caches with correct Content-Type
• App-hosted (Webflow, Squarespace, Shopify): each has a built-in ads.txt manager in admin settings

Step 4: Verify

After deployment:

# Verify file is reachable
curl -I https://yourdomain.com/ads.txt
# Expect: HTTP/2 200, Content-Type: text/plain

# Verify content matches expectations
curl -s https://yourdomain.com/ads.txt | head -20

Then run a public validator (see Tools section below) and check that each SSP’s dashboard recognizes your publisher account in the file. Most SSPs show ads.txt status in their account settings within 24-72 hours of any change.

Common validation errors and how to fix them

These are the issues that show up repeatedly in ads.txt validator results:

Error	Cause	Fix
MIME type mismatch	Server returns text/html or application/octet-stream	Configure server to serve .txt as text/plain
BOM character at start	Saving from Windows Notepad in UTF-8 mode	Re-save without BOM (use VS Code, vim, or Notepad++)
Tab separators	Spreadsheet-exported file uses TAB instead of comma	Replace all tabs with commas
Trailing whitespace	Editor adds whitespace to end of lines	Strip trailing whitespace; configure editor to do this on save
Unreachable apex	DNS only points subdomain to server	Ensure the apex domain serves ads.txt, not only www.; or set up a redirect
Crawler blocked	Robots.txt or Cloudflare blocks the common crawler UAs	Allow iabtechlab.com, IAS, DoubleVerify, and SSP crawler UAs
HTTPS-only redirect	Some legacy crawlers request HTTP	Serve ads.txt over both HTTP and HTTPS, or accept the 301 redirect
Stale entries	Old SSP relationships left in file after offboarding	Remove the lines; a stale DIRECT entry remains a valid signing authority
Whitespace inside fields	pub-12345 67890 instead of pub-1234567890	Remove inline whitespace; field values must be contiguous
Wrong publisher_account_id format	Pasted full URL like https://google.com/ads?id=pub-12345 instead of pub-12345	Use only the SSP-provided account ID, no URL prefix

When entries are valid but bids still get rejected

If your ads.txt validates clean but you still see SSPs reporting your domain as “not authorized,” check three additional things:

1. Canonical domain mismatch. If you list rubiconproject.com but the SSP signs bids as magnite.com, the DSP cannot match. Check the exact canonical domain each SSP uses in bid_request.ext.schain.
2. The SSP’s own sellers.json. If sellers.json says your publisher_id corresponds to a different domain, the chain breaks. Open a ticket with the SSP to fix their record.
3. TAG-ID mismatch. Optional field, but some buyers require it. If your line includes a TAG-ID that doesn’t match the SSP’s certificate, some buyers filter it.

ads.txt and fraud: what it catches, what it misses

ads.txt is narrowly scoped. It targets one fraud vector, domain spoofing, and does so effectively. After widespread adoption, IAB Tech Lab studies showed measurable reduction in spoofed inventory in major exchanges. ^[1]

But ads.txt does not catch:

• Bot traffic to authorized publisher inventory (the bid is from a legitimate seller, the page view itself is bot-generated)
• Made-for-Advertising (MFA) sites that have legitimate ads.txt files but generate worthless ad slots through coercive UX
• Ad stacking and pixel stuffing within authorized publisher pages
• Click fraud on the resulting ad impressions
• Click farms that interact with ads on authorized inventory

In other words, ads.txt closes the seller-identity question. It does not address whether the traffic delivered to those authorized impressions is real, intentioned, or valuable. That is the work of multi-signal click fraud protection, which combines technical fingerprinting, behavioral analysis, and network intelligence to score each user interaction. See our click fraud detection guide for the signal layers and the IVT framework.

For advertisers and DSPs running modern programmatic stacks, ads.txt is necessary but not sufficient. It belongs in the same defensive layer as IVT filtering, pre-bid filtering, and SupplyChain Object validation: each addresses a different slice of the fraud surface.

Tools and validators

The most useful tools in the ads.txt ecosystem:

Tool	What it does	URL pattern
IAB Tech Lab ads.txt validator	Official validator from the spec owner	iabtechlab.com/ads-txt/validator/
Adsworthy ads.txt validator	Third-party validator with permissive checking	adsworthy.com/tools/ads-txt-checker
OpenX ads.txt validator	Validator with detailed line-by-line errors	openx.com/ads-txt-validator
Sincera ads.txt monitor	Continuous monitoring for ads.txt changes across publishers	sincera.io
Pixalate Trust Suite	Compliance scoring including ads.txt + sellers.json + SupplyChain	pixalate.com
Adstxt Crawler (open source)	Self-hosted crawler that follows the official IAB methodology	github.com/InteractiveAdvertisingBureau/adstxtcrawler

For internal teams managing ads.txt at scale, the open-source IAB crawler is the canonical reference implementation. It parses files the same way DSPs do, so anything it accepts will be accepted by buy-side platforms.

When ads.txt changes break supply paths

A particularly painful failure mode: a publisher updates ads.txt to remove a stale SSP, but that SSP is still running campaigns through the publisher’s own ad server (header bidder, prebid module, etc.). The SSP keeps sending bid requests that DSPs now reject as unauthorized. The publisher sees revenue drop with no obvious cause.

Mitigation:

1. Coordinate offboarding. Before removing an SSP from ads.txt, also remove it from your header bidder and direct ad server. Both directions.
2. Run an ads.txt-monitor. Tools like Sincera flag when your file changes and when SSPs report new errors against you.
3. Keep a changelog comment block. At the top of ads.txt, comment the date and reason for each major change. When troubleshooting a revenue drop, the changelog is the first place to look.

How ads.txt fits into the broader transparency framework

The IAB Programmatic Transparency framework has three pieces:

1. ads.txt + app-ads.txt: publisher declarations of authorized sellers
2. sellers.json: SSP declarations of which publishers they represent
3. SupplyChain Object (schain): bid-request-level declaration of the full seller chain

Each piece without the others is partial protection. ads.txt without sellers.json means buyers cannot verify the SSP’s own claim about who the publisher is. SupplyChain Object without ads.txt means the chain looks complete but the top-of-chain seller might not actually be authorized. The three together form a verifiable claim chain from impression back to publisher.

Most quality DSPs in 2026 require all three to be present on any bid they buy. Buying from inventory missing any layer is a deliberate choice that comes with elevated fraud risk.

Adoption status in 2026

By the end of 2025, ads.txt was effectively universal among top web publishers, with adoption above 95% in the Comscore-1000 and similar quality cohorts. ^[1] app-ads.txt adoption is lower but climbing, with significant gaps among mid-tier mobile publishers and gaming apps.

The remaining 5% gap on web is concentrated in two categories:

• Smaller niche publishers who do not work with major SSPs and have no economic incentive
• Publishers using ad networks that bundle ads.txt opaquely: the ad network manages ads.txt on a single shared subdomain rather than the publisher’s apex

For publishers in the second category, the trade-off is convenience versus transparency. Bundled ads.txt works for low-CPM display, but premium buyers will discount or refuse bids where the schain cannot resolve to a publisher-owned apex.

Why ads.txt matters more than ever in 2026

The combination of programmatic complexity, AI-driven bid manipulation, and the rise of CTV programmatic has made supply-chain transparency a higher-stakes problem than it was in 2017. Domain spoofing has not gone away. It has shifted to harder-to-detect vectors like spoofed CTV apps and lookalike domains targeting newly launched publishers who have not yet set up ads.txt.

For media buyers, the practical implication is simple: check ads.txt as part of buying-side due diligence, not just supply-side compliance. If a campaign is winning bids from a publisher whose ads.txt does not include the originating SSP, that is not a clever supply path. It is fraud entering the buy.

For publishers, keep ads.txt curated, dated, and audited. A bloated file with twenty stale SSPs is worse than a tight file with five active ones; each stale entry is a signing authority you do not control.

Where Adsafee fits

Adsafee monitors ads.txt and sellers.json compliance as part of multi-signal click fraud protection. When a bid resolves through a supply chain whose top-of-chain seller is missing from the publisher’s ads.txt, or where sellers.json contradicts the bid request, we flag the click and ship evidence-grade reports to advertisers for refund disputes. ads.txt is one signal among many in our scoring engine, it pairs with behavioral, technical, and network-layer signals for the full picture.

If you want to see whether your traffic is being protected against domain spoofing and the broader fraud surface, start a free trial, first audit takes about 10 minutes.

---

Sources

1. IAB Tech Lab, “ads.txt Specification” (current version) and the IAB Tech Lab Transparency Center: adoption statistics across the Comscore-1000. Visit: iabtechlab.com/ads-txt/. ↩

2. Association of National Advertisers, “Q2 2025 Programmatic Transparency Benchmark”: annual programmatic supply-chain losses. ↩

3. IAB Tech Lab, “app-ads.txt Specification”, released March 2019: extension of the framework to mobile apps via developer website URL anchoring. Visit: iabtechlab.com/ads-txt/. ↩