How to check a site's ads.txt and confirm each seller by hand
Part of Supply path transparency
The short answer
To check ads.txt, open the root domain's /ads.txt in a browser, confirm it returns plain text, and list each line's system domain, account ID and DIRECT or RESELLER label. Then open each system's /sellers.json, search for the account ID and confirm the seller type and name agree. Record the date, the file headers and every match.
Key takeaways
- Start from the root domain, the public suffix plus one name, and open /ads.txt over HTTPS; a page that loads but is not plain text does not count.
- Every line's account ID should appear as a seller_id in the sellers.json file on that line's system domain, with a seller type that fits the label.
- A mismatch is a question for the publisher or the exchange, not proof of fraud, but a buyer should not activate that path until it is answered.
- The response headers say how fresh a copy is, and a dated log of what was found is what makes the check useful later.
How do you open and read a site's ads.txt file?
No tool is needed for one site, only a browser and ten minutes. The ads.txt 1.1 specification (opens in a new tab) defines where the file lives and how a reader should treat what comes back, and the manual check simply follows those rules in order. This walkthrough assumes the reader knows what the fields mean; the ads.txt explainer covers each one.
Definition
- Root domain (for ads.txt)
- The public suffix plus one name, so shop.example.co.uk becomes example.co.uk. The specification tells crawlers to use the Public Suffix List to work it out, and publishers post the file there.
Opening the file the way a crawler would
- Work out the root domain. Strip subdomains down to the public suffix plus one name. If the plan buys a subdomain, note it; the root file decides whether that subdomain has its own list.
- Open the HTTPS address. Type https:// plus the root domain plus /ads.txt. The specification says HTTPS data should be preferred when the same file is available over both.
- Open the developer tools before you trust the page. In Chrome, the Network panel reference (opens in a new tab) explains how to select the request and read its Response Headers. Tick Disable cache and reload, so you see the server's copy rather than an old one.
- Confirm the type and the final address. The Content-Type should be text/plain; the specification says any other type is an error and the content is ignored. Note any redirect and where it ended.
- Copy the records out. Ignore anything after a # character, which marks a comment. Write down each record's system domain, account ID and label, plus any lines of the form NAME=VALUE, such as OWNERDOMAIN or MANAGERDOMAIN.
Two details trip up manual readers. Fields may contain spaces or tabs around the commas, and the specification tells readers to ignore whitespace, so a ragged line is still valid. And anything after a semicolon at the end of a record is an extension field added by an implementer; it does not change the three core fields.
How do you confirm a seller ID in sellers.json?
Each ads.txt line points to an advertising system, and the sellers.json specification (opens in a new tab) says every advertising system listed in an ads.txt file should publish a sellers.json file at /sellers.json on its own domain. The file is JSON, can be large, and lists every seller the system represents. The specification adds that all sellers must be included even if they are confidential, so an account that is missing is missing, not hidden.
Looking up one ads.txt line in sellers.json
- Open the system's file. Use the first field of the ads.txt line as the domain and add /sellers.json. Expect Content-Type application/json.
- Search for the account ID. Use the browser's find, or download the file, and look for a seller_id value equal to the second field of the line. Copy the ID exactly, including prefixes and leading zeros.
- Read seller_type. PUBLISHER means the inventory is on a site, app or medium owned by the named entity and the system pays them directly; INTERMEDIARY means it is not owned by them or they are not paid directly; BOTH covers both.
- Read name and domain. For a DIRECT line, the domain should match the site's OWNERDOMAIN, or the site's own domain when no OWNERDOMAIN is declared, which the ads.txt specification says to assume.
- Follow intermediaries one step. For an INTERMEDIARY or BOTH entry, the specification says the domain should be the root of that seller's own sellers.json. Open it and look for the site's owner there.
What does a mismatch between the two files mean?
A mismatch can come from a slow edit rather than bad intent: a publisher drops a partner but forgets the line, or an exchange renames an account. The specifications do not tell a buyer what to conclude from each one, so the table below gives a reading and an action for each case, with the limit of each reading stated.
| What you found | Possible reading | What to do before buying |
|---|---|---|
| ID in ads.txt, ID in sellers.json, labels agree, owner named | A confirmed path | Record it; confirm the trading desk can buy through that system |
| ID in ads.txt, no matching seller_id in sellers.json | A stale line, a typo, or an account the exchange closed | Ask the publisher's ad operations contact which ID is current |
| DIRECT in ads.txt, INTERMEDIARY in sellers.json | The site may use a partner's account and label it wrongly, or the exchange typed it wrongly | Ask the publisher who controls the account; hold the path until answered |
| DIRECT and PUBLISHER, but the name and domain belong to another company | A sales house or parent company may hold the account; OWNERDOMAIN may explain it | Compare with OWNERDOMAIN and MANAGERDOMAIN; ask if neither matches |
| Matching entry marked is_confidential 1 | The seller asked the exchange to hide its identity | Accept only if another named path is unavailable, and note it |
| No sellers.json at the system domain | The system does not follow the standard, or uses another domain | Ask the exchange where its file is; the path cannot be confirmed meanwhile |
Buying platforms make their own call on these cases. Google's Display & Video 360 help (opens in a new tab), checked in October 2026, says sellers not declared in the publisher's file are treated as unauthorized and blocked, and that inventory with no ads.txt or app-ads.txt file is non participating, which the buyer can include only by changing the inventory source quality setting. A manual check tells the planner what the platform is likely to do before the campaign finds out.
How do you check the file is current?
Neither file carries a date of its own. The sellers.json version field only says 1.0, and ads.txt has no date line. Freshness comes from the HTTP response and from comparing copies over time. Both specifications say consuming systems should honor standard HTTP cache controls, noting the Expires header, and should default to an expiry of 7 days when no cache control directives are present. A buyer's platform may therefore be acting on a copy up to a week old.
Freshness checks for one site and one exchange
- The browser cache was disabled and the page reloaded before reading the file.
- The Last-Modified response header, where present, was noted; RFC 9110 (opens in a new tab) defines it as the time the server believes the representation was last modified.
- Cache-Control and Expires headers were noted, since they set how long other systems may keep their copy.
- The new copy was compared line by line with the last saved copy, and added or removed lines were listed.
- The CONTACT line, if any, was saved so changes can be confirmed with the publisher.
- The exchange's sellers.json was opened the same day as the ads.txt file, so both sides describe the same moment.
What should be recorded after the check?
A check that leaves no record has to be repeated the next time anyone asks. One row per path, kept with the site list, answers the questions raised at activation and in a post campaign review.
| Field | Example value (fictional) |
|---|---|
| Checked on, and by whom | 2026-10-22, planner initials |
| File address and final address after redirects | https://valleyautoblog.example/ads.txt, no redirect |
| Content-Type, Last-Modified, Cache-Control | text/plain; Last-Modified 2026-10-14; no cache directive |
| System domain, account ID, label | sunrisebid.example, 77310, DIRECT |
| sellers.json result | Found; PUBLISHER; name and domain match OWNERDOMAIN |
| Variables in the file | OWNERDOMAIN=valleymedia.example; CONTACT line present |
| Verdict and next step | Confirmed path; desk buys on this system |
What does a manual check look like on a real plan?
Fictional example
A car wash membership brand in Arizona
A fictional chain of car washes in Phoenix and Tucson wants display ads for its monthly membership beside local news, commuting and auto care content, in English. The trading desk wants a curated deal on one exchange, and the planner checks the 14 candidate sites by hand before sending the list.
An auto care blog serves a clean text file with a DIRECT line on the desk's exchange, and that exchange's sellers.json lists the account as PUBLISHER under the blog owner's domain. A Tucson community news site has a DIRECT line whose account ID is not in the exchange's file at all; the planner writes to the CONTACT address in the site's file and holds the site out of the first deal.
A Phoenix commuting site's only line on the desk's exchange is a RESELLER account that sellers.json types INTERMEDIARY, with a sales house domain whose own file names the site's owner. The planner logs it as a confirmed resold path and keeps the site, noting its Last-Modified date of the previous week.
How does PlacementGraph run this check across a whole list?
Frequently asked questions
Are ads.txt seller IDs case sensitive?
Treat them as exact. The ads.txt specification says the DIRECT or RESELLER field should be read without regard to capital letters, but it says the account ID must contain the same value used in transactions, typically publisher.id in OpenRTB. Copy the ID character for character when searching sellers.json.
What does text after a semicolon in an ads.txt line mean?
It is an extension field. The specification allows implementers to add their own data after a distinct final separator, the semicolon, at the end of a record. Readers who do not use that extension can ignore it; the domain, account ID and label before it still define the authorization.
What if a sellers.json file is too large to open in a browser?
Download it and open it in a text editor or a tool that reads JSON, then search for the seller_id. The specification requires every seller to be listed, confidential ones too, so a large file is normal and not a sign of a problem.
Should a mismatch be reported to the exchange or the publisher?
Start with the publisher, since it writes the ads.txt file and can say which account it intended. The sellers.json specification also offers optional contact_email and contact_address fields for the advertising system, which are the right place to ask when the exchange's entry looks wrong.
Sources
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
- Public Suffix List (opens in a new tab)Public Suffix List project
- Network features reference (opens in a new tab)Chrome for Developers
- RFC 9110: HTTP Semantics (June 2022), section 8.8.2 Last-Modified (opens in a new tab)IETF
- Authorized Digital Sellers (opens in a new tab)Google Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.