An app-ads.txt file is a plain-text declaration that lists the advertising systems authorized to sell a mobile app's inventory, and it must be hosted at a specific web URL the app store crawlers can reach. Each line in the file follows a strict four-field format defined by the IAB Tech Lab: the canonical domain of the advertising system, the publisher or seller account identifier issued by that system, a DIRECT or RESELLER relationship flag, and an optional certification authority ID. Publishers declare this list so that ad buyers can verify that the inventory they purchase traces back to a legitimate owner rather than to spoofed or arbitrage resellers. The file is hosted at the root domain that owns the inventory. A syntactically correct but inaccurate file can silently hurt monetization, so every record should come straight from the ad platform's own setup instructions rather than from memory.
What an App-Ads.txt File Declares
The IAB Tech Lab's ads.txt 1.1 specification, and its mobile counterpart app-ads.txt, standardize one record per authorized seller. The format stays identical to the web version; the only meaningful difference is where the file is published for an app rather than a website. Buyers in turn look up the file before bidding on impressions, so an empty or missing file blocks compliant demand and a wrong record blocks the wrong seller.
The declaration exists to fight domain spoofing and unauthorized reselling, two problems that became endemic in programmatic advertising after 2017. When a buyer pays for inventory claimed to come from a legitimate app and the actual impression originates elsewhere, both the publisher and the advertiser lose revenue and trust. A correctly formatted app-ads.txt turns that verification step into a public, crawlable lookup that travels with the app's declared developer domain.
What You Need from Each Ad Platform Before You Start
You cannot generate a working file from the name of the ad network alone. Each system expects a record built from values only the platform itself provides. Before opening a builder, gather four facts for every seller you want to declare:
- The exchange or SSP canonical domain (for example, google.com, applovin.com, unity.com, or pubmatic.com), copied exactly without scheme, path, port, or trailing slash.
- The publisher or seller account identifier as printed in your dashboard or setup email. Identifiers vary by platform: Google uses a pub- prefix followed by digits, many header bidding partners use a numeric ID, and a few use an alphanumeric seller ID.
- The relationship flag: DIRECT if your company controls the seller account and has a direct contract with the exchange, or RESELLER if a third party (often a managed ad operations partner) controls the account.
- An optional certification authority ID. Only include this when the platform explicitly publishes one for your seller record, because identifier values are not interchangeable across exchanges.
Do not invent, convert, or guess any of these values. If a platform gives you a URL rather than a bare domain, strip everything except the host before pasting it into the tool. Sloppy copying at this stage turns into a deployed record that misrepresents your business relationship.
How to Build the File with the Ads Txt Generator
The Ads Txt Generator enforces the four-field schema in your browser so that you can paste each record, see the formatted line, and remove mistakes before deployment. Treat the process as a checklist per platform rather than a single paste.
- Open the Ads Txt Generator in your browser. The page is purely client-side, so no account details are sent to a server.
- For each authorized ad platform, enter the canonical advertising system domain in field one, exactly as the platform publishes it: bare host, lowercased, with no scheme or path.
- Paste your seller or publisher account identifier in field two, copied from the platform's own dashboard or setup instructions rather than retyped.
- Choose DIRECT or RESELLER in field three based on whether your team controls the account directly or works through an authorized third party.
- Leave field four blank unless the platform's setup documentation provides a specific certification authority identifier for that seller record.
- Add the entry to the list, review the generated line, and repeat for every authorized seller you want to declare.
- Scan the full text for duplicates, obsolete records, or pasted artefacts such as leading or trailing whitespace. The generator trims surrounding whitespace and rejects duplicate rows automatically, but it cannot tell whether a record is still authorized.
- Copy the final text or download the newline-terminated file directly to your computer.
The generator caps the list at 200 records so a mistaken oversized paste cannot produce an unwieldy output, and the resulting file ends with a trailing newline that the IAB specification expects.
Where to Host the File So Crawlers Can Reach It
Web crawlers look for the ads.txt file at the root domain that owns the inventory. The expected public location for example.com is /ads.txt on that root domain, and the file must be served as a plain text document with the text/plain MIME type. Publishing the file only under /files/ads.txt, inside an HTML page, or behind authentication does not create the same crawler-visible root resource.
The most common publishing failures have nothing to do with the file's content:
- Hosting the file under /files/, /public/, or a CMS-managed path instead of the root.
- Returning HTML wrapping the plain text, which breaks some crawlers and validators.
- Adding authentication, redirects, or query parameters that change the resolved URL.
- Pointing the store listing at a developer domain that does not actually publish the file at the expected path.
After deployment, open the public URL in a private browser window and read it as plain text. The lines you see in the generator should match character for character, including case, commas, and the trailing newline.
Field Format and Validation Rules
Every record in the file must pass four checks before it is considered crawlable. The Ads Txt Generator applies these automatically, but knowing them helps you spot issues when you copy values from emails or PDFs.
| Field | Required | Format | Common mistake |
|---|---|---|---|
| Advertising system domain | Yes | Bare, lowercased DNS host such as google.com | Pasting https://, leaving a trailing slash, or including a path |
| Seller or publisher account ID | Yes | Identifier as published by the exchange | Converting between formats or omitting a platform-specific prefix |
| Relationship | Yes | Literal DIRECT or RESELLER | Selecting the wrong relationship even when every other field is correct |
| Certification authority ID | No | Exact identifier from the platform | Copying Google's f08c47fec0942fa0 example into a non-Google row |
The generator lowercases the domain, trims surrounding whitespace, rejects commas or internal spaces inside any field, and rejects exact duplicate rows. Subdomains, punycode hosts, and a trailing root dot are accepted. Schemes, ports, usernames, and passwords are rejected. These rules mean the page validates syntax, not authorization, so a record can pass every check and still harm monetization if it misrepresents your business relationship with the exchange.
Mistakes That Break an Otherwise Valid File
Technically valid files still fail in production. The patterns below show up repeatedly across publisher audits and exchange support tickets.
Removing existing valid sellers when adding a new one. The file is a cumulative declaration, not a replacement. Each entry is one more authorized seller, so pruning records you do not recognize can cut off legitimate demand without warning.
Reusing Google's example identifier. The sequence f08c47fec0942fa0 is the certification authority identifier Google uses in its own documentation. It does not apply to other exchanges and should not appear in any non-Google row, no matter how plausible a four-field example looks.
Treating a syntactically valid file as authorized. The generator cannot sign into an ad account, confirm that a publisher ID belongs to your company, or prove that a reseller is permitted. Every record must come from current platform instructions rather than from memory or a stale dashboard screenshot.
Skipping the public URL check after deployment. A record that uploads cleanly to your CMS but renders inside an HTML page, returns a 404, or sits behind a login wall will not be seen by buyers. Open the deployed URL in a fresh browser, treat it as plain text, and compare each line with the source instructions.
For a deeper walkthrough of the file's role in monetization and how the deployment step fits into a broader publisher workflow, see our step-by-step guide to creating and publishing an ads.txt file. The official IAB Tech Lab specification, available at https://iabtechlab.com/wp-content/uploads/2022/04/Ads.txt-1.1.pdf, defines every field, edge case, and crawler expectation that the generator enforces.