Ads.txt Checker Guide: Validate Your Ads.txt Line by Line
Ads.txt is a small text file with an outsized job. Published at the root of a website, it declares which advertising sellers are authorised to sell that site's ad inventory. Buyers check it before bidding, and an entry that is mistyped, incomplete, or missing can mean that legitimate inventory goes unsold, or that an unauthorised seller is not flagged as expected. The file itself is plain text, one declaration per line, which makes it easy to write and equally easy to get subtly wrong.
The Ads.txt Checker tool checks pasted ads.txt content line by line. You paste the file's contents, and it validates each line's fields, flagging lines that do not match the expected shape. It does not fetch the live file from your site, verify that a seller account is real, or confirm that the file is published at the correct address. Those are separate checks you still need to do. What the checker gives you is a clean, pre-publication pass: a file that passes here is at least well-formed, which removes an entire class of silent failures before the file ever goes live.
A standard ads.txt data line has four fields, separated by commas. The first is the advertising system's domain, such as google.com. The second is the publisher account identifier within that system, a code that must match exactly, character for character. The third is the relationship type, either DIRECT, meaning the publisher directly controls the account, or RESELLER, meaning an intermediary is authorised to sell. The fourth, optional field is a certification authority identifier, a tag that identifies the certifier of the advertising system. Lines starting with a hash character are comments, and blank lines are ignored. Every other line is expected to follow the four-field shape, and the checker flags anything that does not.
A worked example you can follow
Take a sample file with three lines: "google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0", "example-ads.com, 98765, RESELLER", and "google.com, pub-1234567890123456, DIRECT". The first line has 4 fields: domain, account, DIRECT, and a certification tag, so it passes. The second line has 3 fields: domain, account, and RESELLER, with the optional fourth field omitted, which is allowed, so it passes. The third line duplicates the first line's domain and account but omits the tag; it is still well-formed, but the duplication is worth noticing, because a duplicate line adds nothing and suggests a copy-and-paste slip. Three lines in, three lines well-formed, but only two distinct declarations, since 3 minus 1 duplicate equals 2 unique entries.
Now take a broken sample of three lines: "google.com pub-1234567890123456, DIRECT", "google.com, pub-1234567890123456, PARTNER", and "google.com, , DIRECT". The first line fails because the first comma is missing, so the checker sees 2 fields instead of the expected 3 or 4, and the domain and account run together. The second line fails because PARTNER is not a valid relationship type; the only valid values are DIRECT and RESELLER, so 1 invalid value invalidates that line. The third line fails because the account field is empty, and an empty account authorises nothing. Fix each line individually, count the fields again, and re-check the whole file, because a file is only as clean as its worst line.
A useful counting check for a longer file: if your file has 40 lines, of which 5 are comments and 3 are blank, then the checker should evaluate 32 data lines, because 40 minus 5 minus 3 equals 32. If it evaluates a different number, a comment may be missing its hash, or a blank line may contain a stray space that turns it into a data line. That arithmetic catches formatting slips that a visual scan misses.
Common mistakes to avoid
The first mistake is publishing a file that was never checked, on the assumption that plain text cannot go wrong; in ads.txt, a single missing comma breaks a declaration. The second mistake is mistyping the publisher account identifier, which is the most consequential field, because buyers match on it exactly. Copy it from the advertising system rather than typing it. The third mistake is labelling a reseller as DIRECT, or the reverse, which misstates the relationship and can affect how buyers treat the inventory. The fourth mistake is checking a draft in the tool but publishing a different version, for example by editing the live file afterwards without re-checking. Always check the exact text you publish, and re-check after any edit.
The Word Counter tool can confirm how many lines you pasted, and the Text Case Converter tool is handy for normalising a relationship value typed in lowercase, since DIRECT and RESELLER are uppercase by convention. For background on keeping a site's public files in order, see Configure Robots.txt.
Checking the result before you publish it
A passing check is necessary but not sufficient. After the content passes, confirm the file is published at the site's root under the exact name ads.txt, confirm it is served as plain text, and confirm the published content matches the checked draft character for character, especially the account identifiers. Then allow time for buyers' crawlers to pick up the new file, and re-check the live content after any future edit. A well-formed file, published in the right place, with matching identifiers, is what turns a small text file into a reliable declaration of who may sell your inventory.
A final habit that protects a clean file is version control for the published text. Keep a dated copy of every version you publish, and note what changed in each version, such as a new seller added or an old account removed. When a buyer reports a problem, or revenue changes unexpectedly, the dated copies let you compare the current file with the previous one and identify the exact line that changed. Without those copies, you are left guessing whether the file changed at all, and when. A simple folder of dated text files, updated whenever the live file changes, is a small discipline that pays for itself the first time a discrepancy needs explaining.