ONIX — short for ONline Information eXchange — is the international standard XML format the book industry uses to describe books and share those descriptions between computers. If a colleague, distributor, or retailer has ever asked you for “an ONIX file” or “an ONIX feed,” they were asking for structured data, not a spreadsheet or a catalogue PDF: a machine-readable record of your titles that their systems can load directly. Wondering “what is ONIX, exactly, and why everyone keeps asking for it”? This guide answers that in plain language. 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 of that work: the hardcover, the paperback, the EPUB, the audiobook. Each product gets its own ISBN-13, so bookshops can order the exact version a customer wants.
An ONIX product record describes one product. So one work with four editions produces four records, each with its own ISBN, price, format, and publication date. ONIX 3 can also link those records back to a shared work identifier, which helps retailers group editions on one page.
ONIX 2.1, 3.0, and 3.1
Three releases are in circulation. ONIX 2.1 dates from the early 2000s and is still widely used; it is frozen, meaning it no longer receives updates. ONIX 3.0 (2009) restructured the format significantly — it handles digital products more cleanly — and is not backward compatible with 2.1. ONIX 3.1 is an incremental update to 3.0: files valid under 3.0 are also valid under 3.1, so upgrading is relatively painless.
The catch is that adoption is uneven. Some receivers still require 2.1, some accept both, and some prefer 3.x. Many publishers maintain both, or generate one and convert. Always check what each trading partner expects 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 inverts that work: the publisher maintains one source of truth, generates ONIX, and every update propagates to all receivers at once. Retailers prefer it too: structured files load cleanly without manual handling. The result is faster title setup, more consistent data everywhere the book appears, and far less copy-paste.
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 means your titles do not get set up or updated: missing product pages, stale prices, lost preorders. Validating before you send catches these problems while they are still cheap to fix. Our guide to validating ONIX 3 files walks through 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.