Key Takeaways

• ads.txt is maintained by publishers and declares who is authorized to sell their inventory. It lives on the publisher's domain and lists SSPs and account IDs with explicit permission to sell.
• sellers.json is maintained by SSPs and confirms the identity of every seller on their platform. It lives on the SSP's domain and maps account IDs to real business names and domains.
• Neither file is a substitute for the other. ads.txt without sellers.json gives authorization without identity. sellers.json without ads.txt gives identity without authorization. DSPs need both.
• DSPs cross-reference both files on every bid request. The account ID in ads.txt links to the identity in sellers.json. When both match, the DSP can verify the full supply path.
• Publishers control ads.txt. SSPs control sellers.json. This division of responsibility means publishers must work with their SSPs to ensure both sides of the verification chain are accurate.

---

sellers.json vs ads.txt: Different Roles, Same Goal

Publishers hear about ads.txt and sellers.json in the same conversations, often in the same sentence.

Both relate to supply chain transparency. Both affect how DSPs evaluate inventory. Both can cost you revenue when they're wrong.

But they're not the same thing. They're two halves of a single verification system, maintained by different parties, serving different purposes. Confusing the two, or assuming one covers what the other does, leads to verification gaps that cost real money.

What ads.txt Does

ads.txt (Authorized Digital Sellers) is a text file that publishers host on their own domain at https://publisher-domain.com/ads.txt. It contains a list of every SSP, exchange, and reseller authorized to sell the publisher's inventory.

Each line follows a standard format:

text
exchange-domain.com, account-id, DIRECT, tag-id

The file answers one question: Who has permission to sell my inventory?

Publishers create ads.txt. Publishers maintain it. Publishers decide which SSPs and resellers appear in it. The file lives on the publisher's infrastructure and is entirely under publisher control.

When a DSP receives a bid request claiming to come from nytimes.com through AppNexus, the DSP checks nytimes.com/ads.txt to confirm that AppNexus with that specific account ID is authorized. If the entry exists, the authorization check passes.

What sellers.json Does

sellers.json is a JSON file that SSPs and exchanges host on their own domain at https://ssp-domain.com/sellers.json. It contains the identity of every seller registered on the SSP's platform.

Each entry includes:

• seller_id: Account identifier (same ID used in ads.txt entries)
• name: The seller's business name
• domain: The seller's website domain
• seller_type: PUBLISHER or INTERMEDIARY
• is_confidential: Whether identity details are hidden

The file answers a different question: Who is this seller, and are they who they claim to be?

SSPs create sellers.json. SSPs maintain it. SSPs decide what information appears for each seller. Publishers have no direct control over their entries in an SSP's sellers.json.

When a DSP checks sellers.json, it verifies that the account ID behind the bid request belongs to a real, named entity with a verified domain. This is identity confirmation, not just authorization.

The Critical Difference

| | ads.txt | sellers.json |

|---|---|---|

| Maintained by | Publishers | SSPs / Exchanges |

| Hosted at | Publisher's domain | SSP's domain |

| File format | Plain text | JSON |

| Purpose | Authorization | Identity verification |

| Key question | "Who can sell my inventory?" | "Who is this seller?" |

| Publisher control | Full control | No direct control |

| Standard body | IAB Tech Lab | IAB Tech Lab |

| Introduced | 2017 | 2019 |

The distinction matters because each file alone is insufficient for full verification.

ads.txt alone tells a DSP that account 12345 on SSP-X is authorized to sell for publisher.com. But it doesn't tell the DSP who account 12345 actually is. The account could belong to the publisher. It could belong to a reseller. It could belong to a bad actor who gained access.

sellers.json alone tells a DSP that account 12345 on SSP-X belongs to "Publisher Corp" at publisher.com. But it doesn't tell the DSP whether Publisher Corp authorized SSP-X to sell their inventory. The SSP might have onboarded the publisher without proper authorization.

Both together create the full picture. ads.txt confirms the publisher authorized the sale. sellers.json confirms the seller's identity matches. The account ID is the link between the two files.

How DSPs Use Both Files Together

When a DSP evaluates a bid request, the verification process works like this:

1. Extract the claim. The bid request says: "This is inventory from publisher.com, sold through ssp-x.com, account ID 12345."

2. Check authorization (ads.txt). The DSP fetches publisher.com/ads.txt and looks for an entry matching ssp-x.com with account 12345. If found, the publisher authorized this sale.

3. Check identity (sellers.json). The DSP fetches ssp-x.com/sellers.json and looks for seller_id 12345. If found, it reads the name, domain, and seller_type.

4. Cross-verify. The DSP confirms that the domain in sellers.json (publisher.com) matches the domain in the bid request. The seller_type (PUBLISHER) aligns with the DIRECT designation in ads.txt. The name matches known records.

5. Bid accordingly. If everything checks out, the DSP bids at full value. If any step fails, the bid is discounted or withheld.

This cross-referencing is why mismatches between ads.txt and sellers.json are so damaging. A seller_type of DIRECT in ads.txt paired with INTERMEDIARY in sellers.json creates a conflict. A domain mismatch raises fraud flags. An account ID present in ads.txt but missing from sellers.json means the authorization exists but the identity can't be confirmed.

Common Points of Confusion

"I updated my ads.txt, so my sellers.json should be fine"

No.

Updating your ads.txt has zero effect on sellers.json. The files are maintained by different parties on different domains. Your SSP must update sellers.json independently. Many publishers assume that onboarding with an SSP means both files are handled, but the processes are often disconnected.

"sellers.json replaces ads.txt"

No. sellers.json was introduced in 2019 as a complement to ads.txt, not a replacement. ads.txt adoption was already widespread and provides a different function (authorization vs. identity). Removing ads.txt because you think sellers.json covers everything would eliminate the authorization layer entirely.

"My sellers.json entry is correct, so I don't need to check ads.txt"

Even if your identity is correctly listed in sellers.json, DSPs still check ads.txt first. If your ads.txt is missing the SSP, has a wrong account ID, or uses the wrong seller_type, the authorization check fails before the identity check even happens.

"I can fix my sellers.json entry myself"

Publishers can't directly edit sellers.json. It's hosted and maintained by the SSP. If your entry has incorrect information, you must contact the SSP and request the change. This dependency is one of the most common sources of frustration for publishers who discover verification errors.

What Happens When One File Is Wrong

ads.txt error, sellers.json correct. The DSP checks ads.txt first and fails the authorization step. It never gets to sellers.json. Even a perfectly accurate sellers.json entry is worthless if ads.txt doesn't authorize the sale.

ads.txt correct, sellers.json error. The DSP passes the authorization step but fails the identity check. The bid request is authorized but unverified. Many DSPs will still bid but at a discount, since the supply path is partially trusted.

Both files have errors. The bid request fails both checks. DSPs either exclude the inventory entirely or bid at the lowest tier.

Both files are correct and consistent. Full verification passes. DSPs bid at full value. This is the state every publisher should target.

How to Keep Both Files in Sync

Since publishers control ads.txt and SSPs control sellers.json, keeping them consistent requires coordination:

1. Audit regularly. Use BeamFlow's scanner to cross-verify your ads.txt entries against each SSP's sellers.json. This catches mismatches automatically.
2. Check after SSP changes. When an SSP migrates platforms, rebrands, or updates their systems, verify your sellers.json entry immediately. These events frequently cause data changes without notification.
3. Match seller_type designations. If your ads.txt says DIRECT, your sellers.json entry should show seller_type PUBLISHER. If your ads.txt says RESELLER, sellers.json should show INTERMEDIARY. Mismatches between these values flag the supply path as inconsistent.
4. Verify account IDs. The account ID in your ads.txt must exactly match the seller_id in sellers.json. Even small formatting differences (leading zeros, different casing) can cause verification failures.
5. Report SSP-side errors. When you find a mismatch in sellers.json, contact your SSP immediately with the correct information. Don't just change your ads.txt to match incorrect sellers.json data.

Frequently Asked Questions

Which file is more important, ads.txt or sellers.json?

Both are essential. ads.txt has wider adoption and is checked first by most DSPs. sellers.json provides the deeper identity verification that increasingly determines bid pricing. Neglecting either one creates verification gaps.

Can I have ads.txt without sellers.json?

Yes, and many publishers do because they can't control sellers.json. But your supply chain will only be partially verified. DSPs can confirm authorization but not identity, which limits their confidence and your CPMs.

How often should I check both files?

Quarterly at minimum for a full cross-verification audit. Immediately after any SSP announces platform changes, migrations, or rebrands. Set up automated monitoring for continuous coverage.