App-ads.txt

App-ads.txt is a plain text file, defined by the IAB Tech Lab, that an app developer publishes to declare exactly which advertising sellers and resellers are authorized to sell that app's ad inventory. The name stands for authorized digital sellers for apps, and the file is the mobile-app extension of ads.txt, the same idea built for websites. Because apps have no domain of their own to host such a file, the standard routes buyers to the developer's website — listed in the app store — where the app-ads.txt sits at a known location. Each line names a seller's domain, the developer's account identifier with that seller, and whether the relationship is direct or through a reseller. A buyer's system reads the file and trusts only bids that trace back to a listed, authorized seller.

The point of app-ads.txt is to fight ad fraud, specifically domain and app spoofing, where a fraudster misrepresents low-value or fake inventory as a legitimate, valuable app. Before the standard, a buyer had little way to confirm that inventory offered as a popular game or utility genuinely came from that developer. App-ads.txt closes the gap by making the authorized-seller list public and machine-readable, so demand-side platforms can verify supply and reject bids that do not match. It does not guarantee quality or viewability, and it does not stop every kind of fraud. What it establishes is provenance. If a seller is not in the developer's app-ads.txt, buyers treat that inventory as unauthorized and unsafe, which drains the market fraudsters rely on to move spoofed supply.

App-ads.txt and ads.txt solve the same problem — verifying who may legitimately sell a publisher's inventory — but for different environments, and the mechanics differ because of it. Ads.txt, the original, lives at the root of a website's own domain, so a buyer fetches it straight from the site whose inventory is on offer. Apps have no such domain, so app-ads.txt cannot be hosted by the app itself. Instead the standard uses the developer URL that each app store listing already carries: a buyer looks up the app's developer website and fetches app-ads.txt from there. The file format and purpose are nearly identical to ads.txt. What changes is the discovery path, which bridges the gap between an app and a file that has to live somewhere hostable.

Treat them as one system with two front doors rather than as rivals. A developer with both a website and apps typically publishes ads.txt for the web inventory and app-ads.txt for the in-app inventory, and buyers check whichever applies to the supply in front of them. Confusing the two — expecting an app's authorization to appear in a website's ads.txt, or the reverse — leaves inventory looking unauthorized when it is fine, or unverified when it should be checked. The safe habit is to remember the trigger. A web impression means read ads.txt at the site's domain. An in-app impression means read app-ads.txt at the developer's declared website. Same trust model, same line format, different location, driven entirely by where the inventory actually lives.

For a developer, using app-ads.txt well means publishing it at the developer website named in every app store listing, keeping it complete and current, and listing each authorized seller and reseller with the correct account identifier and relationship type. An out-of-date file is worse than a careful one. Forget to add a new partner and legitimate demand gets rejected. Leave an old partner in and you keep open a door you meant to close. Every monetization partner should be reflected accurately, because buyers will trust only what the file says. Developers should also make sure the developer URL in the app store points to the site actually hosting the file, since a mismatch breaks the very discovery path buyers rely on to find and read it.

For a buyer, using app-ads.txt well means enforcing it — checking that every in-app bid traces to a seller the developer authorized, and declining supply that does not. The failure modes are predictable: developers who never publish the file, publish it at a URL the store listing does not match, or let it drift out of date; and buyers who treat it as a formality rather than a filter. App-ads.txt only works when both sides honor it. It is a provenance check, not a quality score, so pairing it with viewability and brand-safety measures still matters. Used properly, it makes spoofed app inventory genuinely hard to sell, which is the entire reason the standard was created in the first place.

App-ads.txt extends the ads.txt (authorized digital sellers) standard from the IAB Tech Lab to mobile apps, hosted on the developer's website because apps lack their own domain.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where app-ads.txt is a core concern: