ONIX — short for ONline Information eXchange — is the international XML standard the book industry uses to share product metadata. An “ONIX file” or “ONIX feed” is structured, machine-readable data about titles and editions, not a spreadsheet or catalogue PDF. This guide explains what ONIX contains, who uses it, and why validation matters. If you already have a file, you can check it with our free ONIX validator while you read.
What is ONIX used for?
ONIX for Books — the full name of the standard as it applies to books — exists to move title metadata through the supply chain. A book’s metadata (its title, author, price, description, and so on) has to reach every place the book is sold or catalogued: retailers, bookshop ordering systems, wholesalers, library suppliers, and search indexes. Without a shared standard, every publisher would have to reformat the same information for every trading partner. ONIX gives everyone one agreed structure, so a single file can feed many systems. The standard is maintained by EDItEUR, with national groups such as BIC (UK) and BISG (US) contributing.
Who creates, sends, and receives ONIX files
Publishers create ONIX records, usually generated from a title management system rather than written by hand; self-publishers and small presses often use service providers or conversion tools.
Those files are then sent to trading partners: distributors and wholesalers such as Ingram, retailers such as Amazon and Barnes & Noble, library suppliers, and aggregators like Nielsen BookData. Each receiver loads the feed into its own database, where it powers product pages, ordering, and stock records. Because book metadata for Amazon and Ingram must meet each company’s own requirements on top of the standard, senders must produce files that are both valid ONIX and acceptable to each destination.
What a product record contains
One ONIX message can carry many product records. A typical record includes:
- Identifiers, most importantly the ISBN-13
- Title, subtitle, and series information
- Contributors — authors, editors, illustrators, translators — each with a role code
- Publisher and imprint, plus the publication date
- Physical or digital format, page count or duration, dimensions, and weight
- Prices with currency and the territories where they apply
- Subject classifications such as BISAC or Thema codes
- Marketing copy: descriptions, review quotes, author biographies
- Links to cover images and interior samples
- Availability and sales rights by region
How a work, a product, and an ISBN relate to an ONIX record
Three ideas are worth separating. A work is the abstract creative content — the novel itself, independent of any edition. A product is a specific tradeable version: the hardcover, paperback, EPUB, or audiobook. Each product needs a distinct identifier; products assigned ISBNs need separate ISBNs so buyers can order the intended version.
An ONIX product record describes one product. A work sold in four formats therefore needs four records, each carrying the identifier, format, price, dates, and availability for that product. ONIX 3 can also link products to a shared work identifier, helping recipients group related editions.
ONIX 2.1, 3.0, and 3.1
This validator supports ONIX 2.1, 3.0, and 3.1. ONIX 2.1 dates from 2003; EDItEUR ended support in 2017, declared it obsolete in 2023, and withdrew its remaining support files in 2026. ONIX 3.0, released in 2009, significantly reorganized the format. ONIX 3.1 is a later evolution of ONIX 3, but each file must still declare and validate against the release it uses.
Receiver support varies, but reliance on 2.1 is now a growing business risk. Our ONIX 2.1 to ONIX 3 migration guide explains the transition. Check the accepted release, code-list issue, tag style, and additional rules for every trading partner before sending.
Reference tags versus short tags
ONIX offers two ways to name the same XML elements. Reference tags are human-readable: <TitleText>, <PersonName>, <PublishingDate>. Short tags are compact alphanumeric codes for the same elements: <b221>, <b034>, <b003>.
Both styles express exactly the same data under the same standard and code lists, and convert between each other without loss. Short tags produce smaller files; reference tags are far easier to read when debugging. Either is acceptable if used consistently within a message.
Why publishers send feeds instead of filling in retailer forms
Scale is the short answer. A mid-sized publisher might manage several hundred active titles across a dozen trading partners. Entering every title into every partner’s web form — and re-entering it when a price changes, a date slips, or a cover is replaced — consumes days and invites rekeying errors.
A feed lets the publisher maintain one source of truth and send structured updates to many receivers. Each recipient still ingests changes on its own schedule, but the approach reduces rekeying and keeps data more consistent.
Common ways publishers create ONIX
Few publishers write ONIX by hand. The most common routes:
- Title management systems. Publishing software that stores bibliographic data and exports ONIX feeds on demand or on a schedule.
- In-house databases and scripts. Larger houses generate ONIX directly from their internal systems.
- Service providers and conversion tools. Vendors convert spreadsheets or database exports into ONIX, which suits smaller lists.
- Distributor-generated feeds. Some distributors create ONIX on a publisher’s behalf from data supplied in other formats.
Whichever route you use, the output is only as good as the source data — and it still needs checking before it goes out.
Why validation is necessary
An ONIX file can fail in several distinct ways. It may not be well-formed XML, so nothing can parse it. It may be well-formed but break the schema — elements in the wrong order, required fields missing. It may use code values that do not exist in the code lists. And even a fully schema-valid file can violate a specific receiver’s business rules.
A file that fails to load can leave titles unlisted or unchanged. Validating before delivery catches structural problems while they are still easy to correct. Our guide to validating ONIX 3 files explains the checks in detail.
Check your files before you send them
Understanding the standard is the first step; confirming your files conform to it is the next. A validation pass takes seconds and can save days of back-and-forth with trading partners.