Key Takeaways

• ads.txt protects web inventory. app-ads.txt protects mobile app and CTV inventory. They serve the same purpose but target different distribution channels.
• The file format is identical. Same four-field structure, same DIRECT/RESELLER relationship types, same TAG-ID field. If you can write ads.txt, you can write app-ads.txt.
• The critical difference is hosting and discovery. ads.txt is hosted on the publisher's web domain. app-ads.txt is hosted on the developer's website, linked through the app store listing.
• DSP verification follows different paths. For web inventory, DSPs extract the domain from the bid request and fetch ads.txt directly. For app inventory, DSPs trace through the app store metadata to find the developer's website and fetch app-ads.txt.
• Publishers with both web and app properties need both files. They're separate files serving separate verification chains. One doesn't substitute for the other.

---

app-ads.txt vs ads.txt: Key Differences Explained

If you work in programmatic advertising, you've probably heard both terms used almost interchangeably. And at a surface level, they're similar. Both are plain text files that list authorized ad sellers. Both follow the IAB Tech Lab specification. Both exist to prevent fraud and enable supply chain verification.

But they solve the same problem in different environments, and that difference in environment creates meaningful differences in how each file is hosted, discovered, and verified. Understanding these differences matters if you publish on both web and mobile, or if you're evaluating your supply chain coverage across channels.

What They Have in Common

Before diving into differences, it helps to see how much overlap exists.

Identical file format. Both files use the same four-field, comma-separated structure:

text
exchange-domain, account-id, DIRECT/RESELLER, tag-id

A line in ads.txt looks exactly like a line in app-ads.txt. The syntax rules, comment format, and encoding requirements are the same.

Same relationship types. DIRECT and RESELLER mean the same thing in both files. DIRECT means the publisher or developer holds the account on the exchange. RESELLER means an intermediary holds it.

Same sellers.json cross-verification. DSPs cross-reference entries in both files against the SSP's sellers.json to verify the full authorization chain. A DIRECT claim in either file gets checked against the SSP's seller_type and domain fields.

Same goal. Both files exist to answer one question for DSPs: "Is this seller authorized to offer this inventory?" The mechanism is public declaration by the publisher or developer, verified by the buyer.

The Key Differences

1. What Inventory Each File Covers

ads.txt covers web-based inventory. Desktop websites, mobile web, and any property where ads are served within a browser on a domain that the publisher controls.

app-ads.txt covers app-based inventory. Mobile apps (iOS and Android), connected TV (CTV) apps, and any software distributed through an app store where ads are served within the application environment.

If you run a news website at newssite.com and also publish a "NewsSite" mobile app, the website's inventory is covered by ads.txt and the app's inventory is covered by app-ads.txt. They're separate channels requiring separate files.

2. Where the File Is Hosted

This is the most big practical difference.

ads.txt is hosted at the root of the publisher's web domain:

text
https://newssite.com/ads.txt

The connection is direct: the domain in the ad bid request matches the domain hosting the file.

app-ads.txt is hosted on the developer's website, which is linked from the app store listing:

text
https://newssite-developer.com/app-ads.txt

The connection is indirect: the bid request contains an app bundle ID, the DSP looks up the app in the app store, finds the developer's website URL, and fetches app-ads.txt from there.

This indirection exists because apps don't live on web domains. A mobile game doesn't have a URL. It has a bundle ID (com.studio.coolgame). The app store metadata is the bridge that connects the app to its developer's authorization list.

3. How DSPs Discover the File

ads.txt discovery:

1. DSP receives bid request with publisher domain newssite.com
2. DSP fetches newssite.com/ads.txt
3. DSP checks for the seller ID

Two steps. Domain to file. Clean and direct.

app-ads.txt discovery:

1. DSP receives bid request with app bundle ID com.newssite.app
2. DSP looks up the app in the app store (Google Play, Apple App Store)
3. DSP finds the developer website URL from the store metadata
4. DSP fetches developer-website.com/app-ads.txt
5. DSP checks for the seller ID

Four steps. The extra steps create additional points where verification can break: the app store metadata might be incomplete, the developer website might not match, or the app-ads.txt file might be missing from the developer's site.

4. The Role of App Stores

ads.txt doesn't involve any third party in the discovery process. The publisher's domain is the single source of truth.

app-ads.txt depends on app stores as intermediaries. The developer website URL in the app store listing is the trust anchor. If the app store listing doesn't include a developer URL, or if the URL is wrong, the entire verification chain breaks.

This dependency means:

• Developers must keep their app store listings updated with the correct website URL
• App stores must expose the developer URL in a crawlable format
• DSPs must maintain app store crawling infrastructure to discover developer websites

Google Play and the Apple App Store both support this. Smaller or regional app stores may not, creating verification gaps for inventory distributed through those channels.

5. Subdomain Handling

ads.txt has specific rules for subdomains. If blog.newssite.com doesn't have its own ads.txt, DSPs may fall back to checking newssite.com/ads.txt. The spec defines this fallback behavior.

app-ads.txt doesn't use the subdomain concept at all. The IAB Tech Lab specification explicitly notes that the subdomain directive is unused in app-ads.txt files. Apps don't have subdomains. The developer's website is a flat endpoint.

6. Typical SSP/Network Entries

While the format is identical, the SSPs listed in each file often differ because different ad networks serve different channels.

Common in ads.txt (web-focused):

• google.com (AdSense, Ad Manager)
• rubiconproject.com (Magnite)
• pubmatic.com
• openx.com
• appnexus.com (Xandr)

Common in app-ads.txt (mobile/CTV-focused):

• google.com (AdMob)
• applovin.com
• unity.com (Unity Ads)
• inmobi.com
• chartboost.com
• vungle.com (Liftoff)
• ironsource.com (now Unity)

Many ad networks operate across both web and app, so there's overlap. Google, for instance, appears in both files with different products (AdSense/Ad Manager for web, AdMob for apps).

Side-by-Side Comparison

| Feature | ads.txt | app-ads.txt |

|---------|---------|-------------|

| Inventory type | Web (desktop + mobile web) | Apps (mobile, CTV, OTT) |

| File format | 4-field comma-separated | 4-field comma-separated (identical) |

| Hosting location | Publisher's root domain | Developer's website (from app store) |

| Discovery method | Direct domain lookup | App store metadata lookup |

| Subdomain support | Yes (with fallback rules) | No (unused) |

| App store dependency | None | Required |

| IAB Tech Lab release | 2017 | 2019 |

| Industry adoption | Near-universal for major publishers | 66% of top apps, ~24% overall |

When You Need Both Files

If you operate in both web and app channels, you need both files. They're not interchangeable.

Scenario: News publisher with a website and mobile app.

• newssite.com/ads.txt covers the website's web inventory
• newssite.com/app-ads.txt covers the mobile app's in-app inventory (assuming newssite.com is the developer URL listed in the app store)

Both files can live on the same domain. They serve different verification chains. A DSP verifying web inventory checks ads.txt. A DSP verifying app inventory checks app-ads.txt. Neither file is consulted for the other channel.

Scenario: Game studio with no website.

• No ads.txt needed (no web inventory)
• gamestudio.com/app-ads.txt covers all game apps listed under that developer URL in the app store
• The developer needs to create even a minimal website to host the file

Scenario: Ad network acting as a reseller for both web publishers and app developers.

• The network needs to ensure its entries appear in both the publisher's ads.txt (for web inventory) and the developer's app-ads.txt (for app inventory). Separate conversations, separate files, separate verification chains.

Common Mistakes When Managing Both

Using the same entries in both files without verification. Your web SSP entries (ads.txt) and your app SSP entries (app-ads.txt) may be completely different because you use different ad networks for each channel. Copying one file to the other results in entries that fail verification.

Forgetting to update the developer URL in the app store. If you migrate your developer website from oldsite.com to newsite.com, you must update the app store listing. Otherwise, DSPs will look for app-ads.txt at the old URL and find nothing (or find stale data).

Treating app-ads.txt as a lower priority. Because app-ads.txt adoption is lower than ads.txt, some developers assume it's optional. Every major DSP now supports app-ads.txt verification. Skipping it means lower CPMs from verified buyers who bid only on verified inventory.

Not testing the app store to developer website connection. You can have a perfect app-ads.txt file, but if the app store listing points to the wrong website (or no website), DSPs can't find it. Test the full chain: app store listing > developer URL > app-ads.txt accessibility.

Frequently Asked Questions

Can I host ads.txt and app-ads.txt on the same domain?

Yes. Both files can and often do live on the same domain. They're separate files at separate paths: example.com/ads.txt and example.com/app-ads.txt. They're independent and serve different verification purposes.

Does app-ads.txt cover mobile web?

No. Mobile web inventory (ads served in a mobile browser) is covered by ads.txt, not app-ads.txt. The distinction is browser vs. app, not desktop vs. mobile. If a user visits your site in Chrome on their phone, that's web inventory covered by ads.txt.

What if I only have a mobile app and no website?

You still need a website to host app-ads.txt. The file must be served from a web URL. Even a minimal, single-page website that exists solely to host your app-ads.txt file is sufficient. The developer URL in your app store listing must point to this site.

Does the app-ads.txt file cover all of my apps?

Yes, if all of your apps list the same developer website URL in the app store. One app-ads.txt file on your developer website covers all apps that point to that website. You don't need a separate file per app.

Which file should I prioritize if I have limited resources?

Prioritize the channel that generates more ad revenue. For most publishers with both web and app properties, web revenue is larger, making ads.txt the first priority. But don't skip app-ads.txt entirely. A basic file with your primary app SSPs takes 15 minutes to create and immediately improves your app inventory verification.