Supply quality

ads.txt: authorization is different from validation

Understand seller records and what a local file check can actually establish.

Skills Labs Tech editorial · Updated 30 September 2026 · 7 min read · Educational examples

What a record represents

ads.txt lets a publisher declare authorized sellers of its website advertising inventory. A seller record contains an advertising system domain, a seller account identifier, and a relationship such as DIRECT or RESELLER; a certification authority identifier may also be present. The exact seller ID must come from the relevant advertising system. Do not invent IDs or copy another publisher’s records.

Keep the relationship precise

DIRECT describes a direct account relationship with the advertising system. RESELLER describes authorization through a reseller account. These values are not labels for whether a business is trustworthy or whether every transaction is direct. Ask the partner to confirm its expected record and the contractual relationship before publishing.

Validate in layers

Start with local syntax: field counts, empty values, valid relationship words, and duplicate rows. Then check the public root-domain file over HTTPS and inspect the status, redirects, and response content. Finally confirm that the advertising system recognizes the seller ID and that the published authorization matches the intended relationship. Passing syntax checks alone establishes none of those external facts.

Avoid the silent deployment mistake

A file that works in a local folder can still fail after upload. Some servers route unknown paths to the homepage and return HTML with status 200. Open /ads.txt directly and confirm plain text is returned. Recheck after a hosting change. Keep a reviewed history of additions and removals so a mistaken update can be reversed.

Use the tool responsibly

Our local checker flags common seller-record issues without fetching a domain or consulting a partner account. It recognizes common assignment lines separately from seller rows. It is an educational lint tool, not a complete implementation of every extension in the specification. Review the current IAB Tech Lab documentation and partner instructions before changing a production file.

Further reading

IAB Tech Lab ads.txt. Product behavior depends on the version and integration; check the documentation used by your implementation.

Read a sample record carefully

Consider the fictional record example.com, seller-123, DIRECT. The first field identifies an advertising system domain, not necessarily the publisher’s own domain. The second is the account identifier recognized by that system. The third describes the publisher’s relationship with that account. An optional fourth field can identify a certification authority entry. This fictional record illustrates structure only and should not be published as an actual authorization. For a real partner, obtain its exact requested record through an authorized channel and check that the account relationship is correct. A familiar company name is not enough evidence that a supplied seller identifier belongs in your file.

Make additions reviewable

Before adding a seller, record who requested the change, which relationship it represents, and where the account identifier was confirmed. Keep the proposed line separate from the currently published file so the difference can be reviewed. If a partner sends multiple records, ask what role each one serves instead of assuming all of them are necessary. A reviewable process is useful even for a small website because authorization changes can accumulate quickly. The resulting change log should allow you to answer why a particular seller was added and whether the relationship remains active after a contract or integration changes.

Understand duplicate and contradictory records

An identical repeated seller row is usually a cleanup opportunity. A pair of rows with the same advertising system and account but different relationships needs a more careful review. Do not automatically delete one because it appears similar. Compare the actual account relationship and the partner’s instructions, then document the correction. Normalize obvious whitespace during a local comparison, while retaining the exact seller identifier because its semantics belong to the advertising system. Comments can explain operational context, but they do not alter authorization semantics. A local checker can highlight a pattern; an authorized owner still needs to decide the correct published relationship.

Recognize assignments and extensions

Not every non-comment line is a seller record. Specifications include assignment-style information that must be interpreted according to the relevant version. Our checker keeps common assignment lines separate so they are not incorrectly reported as incomplete comma-separated seller entries. That convenience is not full validation of their meaning. Review the current specification when using owner, manager, contact, subdomain, or other extension information. Do not turn a passing result into a claim that every field is semantically correct. The distinction matters when a file can be parsed locally but contains metadata that describes the wrong business or inventory relationship.

Check retrieval from the deployed host

After uploading the file, retrieve the exact public /ads.txt path without a login. Inspect the response status, content type, redirects, and body. Make sure a hosting rewrite has not substituted the homepage. Compare the downloaded text with the intended release, because a successful upload message may not mean that a cache or alternate origin is serving the newest bytes. Repeat the check on the domain submitted to the advertising system. If redirects are involved, inspect them against the specification and partner requirements rather than assuming every redirect chain will be accepted by every crawler.

Plan changes and removals

When a partner relationship ends, review whether its authorization should be removed and whether any other active arrangement depends on the record. Coordinate with the relevant business owner before making the change. Save the preceding version so a mistaken edit can be reversed. After publication, record when the new file became publicly retrievable. External systems may not immediately reflect a change because their retrieval and processing schedules differ. Avoid repeatedly changing the same line in response to a dashboard that has not yet refreshed. Confirm the actual served file first, then investigate the partner’s processing state using its documented support process.

Keep website and app workflows separate

For website inventory, investigate the website’s ads.txt publication. For app inventory, review the app-ads.txt discovery process and the developer website associated with the app store listing. These workflows share an authorization purpose but do not have identical discovery inputs. An app-ads.txt issue may come from an incorrect listing or developer-domain association rather than a malformed seller record. Describe which inventory type is being investigated in every support ticket. Use the relevant specification and platform guidance to confirm the discovery path, and avoid assuming that a website file automatically authorizes inventory from an unrelated application or developer account.

Apply this guide with anonymized fixtures. Add your own verified operational examples when documenting a real integration.