What this tool does
This ads.txt generator writes the authorisation file that tells programmatic buyers who is allowed to sell advertising on your domain. Fill in your AdSense publisher ID and it produces the Google line in full; add the partners you work with, a contact address and any subdomains that serve their own inventory, and it assembles the file. The second tab does the opposite job: paste the file you already publish and it reports, line by line, what a parser makes of it.
Everything happens in this tab. Your publisher ID is not a secret — it is visible in the ad code on every page you serve — but there is still no reason for it to travel anywhere.
The format, in one paragraph
Each line is one authorisation, with fields separated by commas: the ad system's bare domain, your
account ID inside that system, the word DIRECT or RESELLER, and optionally the seller's TAG
certification ID. Anything after a # is a comment. Lines shaped NAME=value are variables, and
only five are defined: CONTACT, SUBDOMAIN, OWNERDOMAIN, MANAGERDOMAIN and
INVENTORYPARTNERDOMAIN. There is no nesting, no quoting and no escaping. That simplicity is the
point — a buyer's crawler has to parse millions of these files quickly — and it is also the trap,
because a malformed line is skipped in silence rather than reported.
Why the file exists at all
Before ads.txt, an exchange had no cheap way to know whether the seller offering your inventory was really entitled to sell it. Domain spoofing worked exactly like that: a fraudster offered impressions labelled as a well-known publisher, a buyer paid the premium those impressions command, and the money went somewhere else entirely. The IAB Tech Lab's answer was to move the answer to a place the buyer already trusts — a text file on the publisher's own domain, reachable over HTTPS at a fixed path.
So the file is not an SEO artefact and it does not affect your rankings. It is an allowlist. A buyer reads it, compares the seller offering the impression against the accounts you declared, and drops the bid if there is no match.
What to check after you publish
Fetch the URL yourself before assuming it works. The three failures that account for most broken
files are a redirect, a wrong content type, and a copy of the file that lives on www while the
canonical host is bare, or the other way around. If both hosts serve pages, both need the file, and
that is also true of every subdomain that carries ads — unless you list them with SUBDOMAIN=,
which points the crawler at the child's own file rather than sharing yours.
Keep the file short and keep it honest. A common habit is pasting a partner's whole published list because it is easier than asking which line is yours; the result authorises dozens of sellers who have nothing to do with your inventory, which is precisely the situation the file was invented to prevent. When a partnership ends, remove the line — a stale RESELLER entry is a standing permission you are no longer supervising.
Related files at the root of your domain
Three unrelated text files live at the root of a domain and get confused with each other. robots.txt tells crawlers what to fetch. Your XML sitemap tells them what exists. This one tells advertising buyers who may sell your inventory, and no search engine reads it. If you are also setting up the domain's mail, the SPF record is the equivalent allowlist for sending servers.