Key Takeaways

• app-ads.txt is an IAB Tech Lab specification that lets app developers publicly declare their authorized ad sellers. It's the mobile app equivalent of ads.txt, extending the same fraud prevention framework to in-app inventory.
• It was introduced in 2019 to address a gap ads.txt couldn't fill. Mobile apps are distributed through app stores, not hosted on web domains. The original ads.txt had no mechanism to map an app to a developer's authorized sellers list.
• 66% of the top 1,000 Google Play apps have adopted app-ads.txt. But overall adoption sits at just 24%. The gap between major publishers and the long tail remains massive.
• Without app-ads.txt, DSPs can't verify in-app inventory. This means unverified bid requests get filtered, reducing demand and CPMs for app developers who skip implementation.
• The format is nearly identical to ads.txt. Same four-field structure. Same DIRECT/RESELLER relationship types. The key difference is where the file is hosted: on the developer's website, linked from the app store listing.

---

What Is app-ads.txt and Why It Exists

If you run ads in a mobile app, you have a problem that web publishers don't.

Your app isn't a website. It doesn't have a root domain where you can drop a text file. When a DSP receives a bid request claiming to represent inventory from your app, it has no straightforward way to verify that the SSP sending the request is actually authorized to sell your ad slots.

This is the exact problem that ads.txt solved for the web in 2017. Publishers post a list of authorized sellers at their root domain. DSPs check the list. Unauthorized sellers get filtered out.

But mobile apps live in app stores, not on web servers. The original ads.txt specification had no way to bridge that gap. Fraudsters exploited this. They spoofed popular apps in bid requests, selling fake inventory that appeared to come from well-known games and utilities. IAB Tech Lab estimated that app-level fraud accounted for billions in wasted ad spend before proper verification mechanisms existed.

app-ads.txt, released by IAB Tech Lab in March 2019, extends the ads.txt framework to mobile apps, connected TV (CTV), and any other app-store-distributed software. The concept is the same: developers publicly declare who can sell their inventory. The mechanics differ because the hosting and discovery process has to account for how apps are distributed.

How app-ads.txt Works

The app-ads.txt verification chain involves four parties: the app developer, the app store, the SSP, and the DSP.

Step 1: Developer Publishes Their Website in the App Store

Every major app store (Google Play, Apple App Store) lets developers list a website URL in their app's store metadata. This URL is the anchor that connects the app to its authorized sellers list.

When you publish an app to Google Play, the developer URL in your store listing becomes the domain where DSPs expect to find your app-ads.txt file.

Step 2: Developer Hosts app-ads.txt on Their Website

The developer creates an app-ads.txt file and hosts it at the root of the website listed in the app store. For example, if your app store listing shows https://developer-site.com, your file goes at:

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

The file format is identical to ads.txt:

text
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
applovin.com, 987654, DIRECT, 123abc456def
unity.com, 112233, RESELLER, aaa111bbb222

Each line declares an SSP or ad network authorized to sell inventory from your apps.

Step 3: SSPs Include Store URL in Bid Requests

When an SSP sends a bid request for in-app inventory, it includes identifying information: the app's bundle ID, the app store URL, and the seller ID. This gives the DSP everything it needs to locate and check the developer's app-ads.txt file.

Step 4: DSPs Verify the Authorization Chain

The DSP receives the bid request and:

1. Extracts the app store URL from the bid request
2. Looks up the developer's website from the app store metadata
3. Fetches developer-site.com/app-ads.txt
4. Checks if the SSP's seller ID appears in the file
5. Verifies the relationship type matches the SSP's sellers.json

If verification passes, the DSP bids. If it fails, the bid request gets rejected.

Why ads.txt Was Not Enough for Apps

The web version of ads.txt relies on a direct connection between the domain in the bid request and the domain hosting the ads.txt file. If the bid request says "this is inventory from example.com," the DSP fetches example.com/ads.txt. Simple.

Mobile apps break this model because:

Apps don't have domains. A game called "Puzzle Quest" doesn't have a natural web domain embedded in its ad inventory. The bid request contains a bundle ID (com.studio.puzzlequest), not a URL.

Multiple apps can belong to one developer. A single developer might publish 20 apps, all of which should share the same authorized sellers list. ads.txt has no concept of mapping multiple properties to one authorization file.

App store metadata is the trust anchor. The app store is the authoritative source that connects an app to its developer. app-ads.txt uses this by using the developer website URL from the store listing as the bridge between the app and its authorized sellers.

The "subdomain" concept doesn't apply. In ads.txt, subdomains have specific rules about inheritance and fallback. In app-ads.txt, the specification notes that the subdomain directive is unused because apps don't have subdomain structures.

What Goes in an app-ads.txt File

The file format mirrors ads.txt exactly:

text
<exchange-domain>, <account-id>, <relationship-type>, <tag-id>

Example:

text
# Direct SSP relationships
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
applovin.com, abc123def, DIRECT
unity.com, 445566, DIRECT, aaa111bbb222

# Mediation partners (resellers)
inmobi.com, 998877, RESELLER, 83e75a7ae333ca9d
chartboost.com, 667788, RESELLER
vungle.com, 556644, RESELLER, 123abc456def

Everything that applies to ads.txt formatting applies here:

• Comma-separated fields
• DIRECT and RESELLER in uppercase
• TAG-ID is optional but recommended
• Comments with # are supported
• Plain text format, UTF-8 encoding

The only structural difference: app-ads.txt typically includes mobile-specific ad networks (AppLovin, Unity Ads, ironSource, Chartboost, Vungle) alongside traditional programmatic SSPs.

Adoption: Where the Industry Stands

The adoption picture for app-ads.txt is mixed. Verve Group's 2025 analysis reported:

• 66% of the top 1,000 Google Play apps have adopted app-ads.txt
• Overall adoption across all apps sits at roughly 24%
• Adoption has been steadily increasing year over year

The gap tells the story. Major publishers with dedicated ad ops teams adopted early. They understand the revenue implications of unverified inventory. Smaller developers and indie studios have been slower, often because they lack ad operations expertise or don't realize app-ads.txt exists.

For app developers in the long tail, this is both a problem and an opportunity. The problem: without app-ads.txt, their inventory is unverified, leading to lower CPMs and restricted demand. The opportunity: implementing app-ads.txt when competitors haven't can provide a verification advantage that improves yield.

What Happens Without app-ads.txt

If your app doesn't have an app-ads.txt file:

DSPs can't verify your inventory. Bid requests from SSPs selling your ad slots have no authorization backing. DSPs that require app-ads.txt verification (and the list is growing) will skip your inventory entirely.

Lower CPMs from remaining buyers. DSPs that still bid on unverified inventory do so with lower confidence. Lower confidence means lower bids. The risk premium is priced into your CPMs.

Your app is vulnerable to spoofing. Without app-ads.txt, fraudsters can forge bid requests claiming to represent your app. If your app has recognizable brand value or high traffic, this is a real risk. Spoofed inventory dilutes your brand in the programmatic marketplace and can eventually cause buyers to avoid your app entirely.

Mediation partner performance looks worse than it is. If your ad mediation platform sends bid requests to DSPs that verify app-ads.txt and your file is missing, those bids get rejected. The mediation platform reports low fill rates and low CPMs. You blame the platform. The real problem is missing verification.

Beyond Mobile: CTV and OTT

app-ads.txt isn't limited to mobile apps. IAB Tech Lab extended the specification to cover connected TV (CTV) and over-the-top (OTT) streaming applications. Apps distributed through Roku, Fire TV, Apple TV, and Android TV app stores can all use app-ads.txt to declare authorized sellers.

The CTV advertising market has grown rapidly, and with that growth came fraud. CTV inventory commands premium CPMs, making it an attractive target for spoofing. app-ads.txt provides the same protection to CTV publishers that it provides to mobile app developers.

The implementation is identical: list a developer website in the app store metadata, host app-ads.txt on that website, and include entries for every SSP authorized to sell your CTV inventory.

Frequently Asked Questions

Is app-ads.txt the same format as ads.txt?

Yes. The file format, field structure, and syntax rules are identical. The difference is where the file is hosted (on the developer's website, linked from the app store) and how DSPs discover it (through app store metadata rather than the domain in the bid request).

Do I need both ads.txt and app-ads.txt?

If you publish both a website and mobile apps, you may need both. ads.txt covers web inventory. app-ads.txt covers app inventory. They're separate files serving separate verification needs. If your developer website also runs web ads, it should have its own ads.txt for that web inventory.

What if my app doesn't have a website?

You need one. Even a simple single-page site that hosts your app-ads.txt file and links to your app store listings is enough. The developer website URL in your app store listing is the anchor that the entire verification chain depends on. Without it, app-ads.txt can't function.

Is app-ads.txt mandatory?

Not technically mandated by app stores. But in practice, the largest DSPs and ad exchanges increasingly require it for verification. Running in-app ads without app-ads.txt is like running a web site without ads.txt: it works, but with reduced demand, lower CPMs, and no protection against spoofing.

How do I check if my app-ads.txt is working?

Visit your developer website and verify the file is accessible at the root path. Then check the app store listing to confirm the developer URL matches. For cross-verification against sellers.json, use a supply chain scanner like BeamFlow to verify every entry.