Font Size:



Frequently asked questions

A separate FAQ document specific to ONIX 3.0 is also available here.


What is ONIX?

ONIX – more specifically ‘ONIX for Books’ – is a standard specification for communicating book, e-book and digital audio metadata between publishers, various intermediaries like distributors, wholesalers and data service organisations, and retailers in the book supply chain.

Metadata – information about each book – has become vitally important to the smooth running of the supply chain and the effective marketing, merchandising and retailing of books and related products. And given both the huge number of books and e-books made available in the market and the rich range of information about each one, a standardised method of communicating this information between supply chain partners is critical. It saves money and speeds up the flow of information by being suitable for highly automated exchanges of data.

Because the ONIX file format is intended and optimised for computer-to-computer communication, it’s not particularly easy for humans to read and interpret. And because it’s focused on communication, ONIX files are usually referred to as ‘ONIX messages’. These messages flow between databases, not between people. But the ONIX metadata framwork also incorporates standardised terminology to ensure that industry terms – and the metadata file that use them – are interpreted consistently by every organisation using ONIX.

How was ONIX for Books created?

ONIX for Books was originally developed jointly by the Digital Issues working group of the Association of American Publishers (AAP), EDItEUR and others in 1999, in response to the growing importance and value of high-quality metadata to publishers and online booksellers. ONIX stands for ONline Information eXchange, and the first version was published in January 2000.

That first version combined ideas about metadata from earlier work including Book Industry Communication’s ‘BIC Basic’ specification, the European Union-funded <indecs> project and EDItEUR’s EPICS data dictionary. It was also influenced by the XML specification released in 1998 by the World Wide Web Consortium. ONIX for Books aimed to reduce the difficulty of managing, distributing and updating large volumes of rich and dynamic metadata. But it was a set of guidelines which EDItEUR developed into a properly specified standard from April 2000 onwards. There have been numerous updates to the standard since then.

Today, ONIX for Books is just one member of a family of XML-based international standards intended to support computer-to-computer communication between parties involved in creating, distributing, licensing or otherwise making available intellectual property in published form, whether physical or digital. It is by far the most widely adopted and implemented member of the family, but there are similar specifications intended for the serials (academic journals) trade, for library licensing, and other specialist uses.

Who is responsible for the ONIX for Books standard now?

While ONIX for Books (from now on, just ‘ONIX’) was originally developed jointly by the AAP, EDItEUR and others, subsequent development and support has been the responsibility of EDItEUR. Book Industry Communication (BIC) in the UK and the Book Industry Study Group (BISG) in the US provided essential support for early EDItEUR development work.

ONIX is now firmly established around the world as the book trade standard for the communication of ‘product metadata’ – bibliographic information, support material for marketing and promotion, and commercial supply-chain information – the rich metadata that is needed to support the sale of books in the supply chain, not least for online retailing.

Ongoing development is managed by EDItEUR, overseen by an International Steering Committee with representatives of ONIX user groups in 25 or more countries including Australia, Belgium, China, Canada, Finland, France, Germany, Italy, Japan, the Netherlands, Norway, Russia, Spain, Sweden and the Republic of Korea, as well as US and UK representatives. The ONIX Steering Committee meets twice a year, at the London and Frankfurt Book Fairs, and is responsible for ensuring the standard develops in line with the needs of the full range of ONIX users.

So where can I buy it?

It’s important to understand that ONIX is simply a specification for a standard method for communication. It is not in itself a database, a software application, or a product or service that you can purchase. Although many software applications, services and databases may well implement the ONIX standard, these are provided by third-parties, and are not supplied or directly supported by EDItEUR.

The ONIX specification, associated documentation and guidance, and a range of XML software tools are available to all and usable without charge: EDItEUR makes everything essential for implementing ONIX available for download on its website, and there are no licensing charges, royalties or fees payable if you make use of the standard.

Note, however, that although EDItEUR is committed to ensure that ONIX is and remains free to use, it is not ‘free’ in the sense that the standard itself and all associated documentation remains © EDItEUR. This is simply to protect the integrity of the standard and the development process. A full licence document is available here.

If ONIX is free of charge, how can EDItEUR support it?

EDItEUR is a not-for-profit, membership-supported organisation. Members of EDItEUR pay an annual subscription, and in return they have a strong voice in the development direction EDItEUR adopts, a vital role in the governance and sustainability of the standard, and better access to EDItEUR’s expertise. They occasionally have early access to new versions of ONIX as they are developed, or they participate in working groups helping define new requirements and revisions to the standard.

Membership of EDItEUR is a visible sign of an organisation’s support for an open, standards-based approach to building an effective supply chain, for the benefit of all stakeholders. But membership is not required to make use of ONIX or any other EDItEUR standard.

Is ONIX only used for ‘books’?

Although the format is formally known as ONIX for Books, it has always covered other media such as audiobooks or recorded video and other products produced by publishers and other organisations which are distributed through the book supply chain. This includes educational software, cartographic products, some toys and games, promotional apparel, point-of-sale items and – of course – digital audiobooks, e-books and electronic devices like e-book readers.

What are the benefits of adopting ONIX?

For publishers, experience has shown that ONIX brings two important business benefits. As a communication format, it makes it possible to deliver rich product information into the supply chain in a standard form, to wholesalers and distributors, to larger retailers, to data aggregators, and to affiliate companies. A single set of data can be suitable for all downstream requirements. And by providing a template for the content and structure of the information about a product, ONIX has stimulated the development of better internal information systems, capable of bringing together all the ‘metadata’ needed for the description and promotion of new and backlist titles. The same core data can also be used to produce advance information sheets, catalogues and other promotional material.

For ‘downstream’ supply chain partners such as distributors and wholesalers, data intermediaries and retailers, ONIX means that they can speed up the loading of up-to-date product information into customer-facing systems, with less need for manual intervention and a much lower risk of error. ONIX reduces the need to deal with multiple proprietary data formats, and hence reduces support costs. And by enabling third parties such as trade associations or data aggregators to develop metrics for data quality and timeliness, it enables benchmarking and encourages overall improvement of the data available throughout the supply chain.

What is the current version of ONIX?

Over the years since the publication of version 1.0 in January 2000, ONIX has undergone continual development – to improve the format itself, to incorporate new types of data, and to ensure the standard keeps pace with evolving business requirements across the book and e-book market.

That initial version 1.0 and a quick succession of minor updates (International 1.0, 1.1, 1.2, 1.2.1) were followed by Release 2.0 in July 2001. These versions are all obsolete.

Release 2.1 – fully backwards-compatible with 2.0 – was released two years later in July 2003 and, following the release of a couple of minor updates containing optional extensions, has been stable since mid-2004. Version 2.1 remains to this day a commonly implemented version in some markets (particularly in the US and Germany). There were also two minor revisions of ONIX 2.1 intended for use in specific countries, the last being rev.04 in early 2011 (intended for use exclusively in Japan).

Release 3.0 was published in April 2009, and has been stable since late 2010. There have been numerous backwards-compatible updates containing only optional additions, from 3.0.1 in early 2012 to 3.0.7 in late 2019 that have extended ONIX 3.0 functionality.

So there is no single ‘current’ version. Releases 2.1 and 3.0 are both in widespread use, though use of 3.0 is increasing rapidly.

The ONIX International Steering Committee announced at the beginning of 2012 that the level of support for 2.1 would be reduced at the end of 2014. The committee gave three years notice of the withdrawal of support, allowing adequate time for planning, budgeting and software development to bring implementations up to version 3.0. This ‘sunset date’ at the end of 2014 should have been seen by organisations using 2.1 as a target for completing their migration to ONIX 3.0, but of course ONIX 2.1 continued to be usable for several years after sunset. In fact, 2.1 is still in current, though diminishing use. All ONIX users are strongly encouraged to update their implementations to the latest 3.0 specification, as not all important ONIX data recipients support release 2.1 and other will cease to support 2.1 beyond 2020.

What are ONIX tags and codelists?

ONIX is an XML data format, and all of the data it contains is embedded inside ‘XML tags’. Tags are markup constructs between < and > characters, and they always occur in pairs, an opening tag and a closing tag. So for example, the name of an author might be held like this:

<PersonNameInverted>Fatale, Natasha</PersonNameInverted>

between two XML tags, and the whole thing is generally termed a ‘data element’. The <PersonNameInverted> element is defined to always hold a (personal) name, family name first, with given names, titles and honorifics following the family name. There are perhaps 450 such ‘tags’ in ONIX. Some hold text data like a name, others hold numbers, like the <SequenceNumber> tag below, or data with a restricted range of values (codes), such as <ContributorRole>. And some other tags are purely structural, grouping together other elements that logically belong together. For example, all data elements associated with a particular author are enclosed within a <Contributor> ‘composite element’:

    <PersonNameInverted>Fatale, Natasha</PersonNameInverted>

Where a data element has a restricted range of values – such as <ContributorRole> – the allowed values are defined in a ‘codelist’ or ‘controlled vocabulary’. There are different codelists for different data elements, about 140 in all. Each lists all the allowed codes, so list 17 (for contributor roles) lists A01, A02 and so on, plus their meanings. A01 means ‘written by’.

The tags, whether they are mandatory or optional, whether they are repeatable, and their nesting within composites, are defined by the ONIX Specification and codified in the ONIX XML schema. Different releases of ONIX use slightly different sets of tags. Codelists are shared between all releases of ONIX, and the codelists are revised regularly to add new terms as new requirements arise. Adding new codes (without having to change the tags themselves) is the main way that the functionality of ONIX is extended to cope with new business requirements.

What are ‘Reference names’ and ‘Short tags’?

Each element in ONIX has a ‘plain language’ reference name (for example, <PersonNameInverted>) and a short tag (for example, <b037>). So:

    <PersonNameInverted>Badenov, Boris</PersonNameInverted>

can also be expressed as:

    <b037>Badenov, Boris</b037>

These are identical in meaning. The schema definitions allow either Reference names or Short tags to be used to label the data elements in an ONIX XML message. They cannot, however, be mixed in the same message.

Short tags make ONIX files around a quarter or a third smaller, though they remain equally complex to process – and zipping files before transmission is considerably more effective in reducing the file size. Reference names make debugging simpler. Users can make a choice between readability and conciseness (though Reference names – often just termed ‘long tags’ are increasingly preferred). For ONIX 2.1 and for ONIX 3.0, there are tagname converters which translate Reference names to Short tags, and vice versa.

NB in the very earliest ONIX releases, the initial letters of the short tags indicated an attempted logical grouping of elements. As the format developed, this grouping quickly became impractical, so that there is now no significance to be drawn from the initial letters. (The numeric part of the tag has always been unique by itself.) In ONIX 3.0, all new elements have been assigned short tags of the form <xnnn>, so that they can be immediately recognised as new.

Does the order of the data elements matter in ONIX XML?

Yes. Elements in an ONIX for Books message must be delivered in the sequence defined by the schema. A message in which elements occur out of sequence will not validate. In the example:

    <PersonNameInverted>Badenov, Boris</PersonNameInverted>

the <ContributorRole> tag must occur before the name and after any sequence number. If it follows the name, or if either is missing, the ONIX is not valid.

On the other hand, where an element or composite is repeated several times (say because there are several contributors, or several subject codes) the order of the repeats is generally not meaningful.

What should I do if I have no information to go in an ONIX data element?

If for a particular product there is no information available or appropriate for an optional data element, the data element should simply be omitted.

So for example, the weight or exact spine thickness of a physical book, or the filesize of an e-book may not be known with any certainty until close to publication. In ONIX sent several months before publication, you should simply omit the entire <Measure> composite for weight or spine thickness, or the entire <Extent> composite for the filesize – though you should still include the <Measure> composites for height and width, and the <Extent> for the notional number of pages.

In contrast, if the element for which the data is missing is mandatory, you must not send an ONIX record without providing valid data for the element. In neither case is it permissible to send an ‘empty element’.

Note that if the element for which there is no information available is a mandatory part of a larger composite element within the message, the whole composite element must be omitted.

[In XML, it is possible to deliver an empty element in either of two forms: <Tag></Tag> or <Tag/>. Neither of these forms should ever occur in an ONIX message, except in a few instances where an element (eg the <MainSubject/> flag in Group P.12 in Release 3.0) is specifically defined as always empty, in which case we strongly recommend that the second form <Tag/> should be used. Aside from the handful of ‘always empty’ elements, if there is no data for an element, the element should be omitted completely. Most ‘illegal’ empty elements are detected by validation against the XSD or RNG schemas, but not by validation against the DTD. Consequently there is a risk with the DTD that a message could pass validation even though it includes mandatory elements for which there is no data. This is a strong reason for using the XSD or RNG schema for validation wherever possible.]

Can ONIX cope with books and metadata in any language?

Yes. ONIX is not built around the needs of any one country, or any one supply chain.

Although the Reference tag names are in English, this is just a convenience, and the data carried within most data elements is language-independent. Whether a book is known as a hardback (English), a hardcover (American English), or eine gebundene ausgabe (German), the ONIX data is the same (<ProductForm>BB</ProductForm>).

Where the data is text in a particular language – for example, the text of a contributor’s biography – the text can be provided in one language or in several languages in parallel.

And to facilitate this text in multiple languages, ONIX data can use Unicode: whether your metadata is in Latin script (for English and most European languages), Cyrillic (for Russian), Arabic script, Hanzi or Kanji (for Chinese and Japanese) or Hangul (for Korean), Unicode covers what you need.

As a publisher, how can I implement ONIX for Books?

The options for publishers who want to adopt ONIX and start sending ONIX messages to their business partners are of three kinds:

  • develop or commission bespoke software for managing product metadata, and build in support for ONIX for Books;
  • acquire a third-party application for product data management which supports ONIX. This can be single user or a multi-user server-based application; or
  • contract to use a web-based ‘in the cloud’ service which supports online data entry and delivery of ONIX output to designated recipients.

The availability and practicality of each of these options will vary to some degree from country to country, and the choices taken by large publishers may be different from small publishers. There are many application and service providers within the ONIX ecosystem, and while ONIX is not so complex it is beyond the abilities of a small internal develpment team, bespoke software development is rarely the right approach for all but the largest publishers.

Some ONIX national groups may be able to provide contacts with system and service suppliers, and a selection are also listed on EDItEUR’s ONIX Users and Services Directory. Wherever possible, EDItEUR provides links to national groups and to system vendors from the ONIX for Books pages on this website.

Will ONIX affect the way I store and manage my product information?

ONIX is a metadata format specifically developed to support the communication of information from one computer system to another. It is not designed as an internal database format. However, it is obvious that communication can only work if the systems at each end are substantially ‘ONIX compliant’ – for example, supporting data element structures and data encoding which are no less exact or granular than those used in ONIX. It is important to verify at the earliest possible stage that any product data management system you plan to use is ‘ONIX compliant’ in this sense.

It is all too easy to deliver something which is technically correct in XML terms, and which validates correctly, but wrong in data content. For example, title fields in some book trade systems are traditionally used to carry added data such as an edition number or binding, which differentiates one product from another. But in ONIX, title elements should carry only the component parts of the title itself, and there are separate data elements for edition numbers and binding types. So not only your internal database structures, but also the disciplines followed by your data management staff, need to be ‘ONIX compliant’.

Do I need to include all elements listed in ONIX for Books?

ONIX aims to cover the widest possible range of needs, and it therefore includes many elements which are specialised to particular forms of publishing or particular markets. Nobody uses all the elements available, and only a very small number are mandatory. The technical minimum (which is implicit in the ONIX schema) is entirely useless, and the effective minimum range of tags in practice depends upon your business requirements and those of your supply chain partners. The minimum set of data elements to support for a trade publisher is a little different from that of an academic publisher or that of a religious publisher.

EDItEUR provides a comprehensive Implementation and Best Practice Guide that offers advice on the most commonly useful ONIX 3.0 data elements.

And in many countries where ONIX has been adopted, national groups publish their own guidelines for implementation and ‘good practices’, building on the global EDItEUR advice. If you are buying a third-party system or service, you need to check that it complies with the EDItEUR guidelines and those extra guidelines that are in use in your particular market(s). Some receivers may choose not to use certain elements, or may ask for one option rather than another. However, no receiver should reject a valid message because it includes optional content which they have chosen not to use (they should just be able to ignore it).

If I send an ONIX message, do I get anything back?

Often, no. You send the message, and the recipient processes it. You cannot easily monitor the appearance of any new or updated data within systems internal to the recipient, but you can monitor the appearance of the data on public websites and the like.

But EDItEUR has defined an 'Acknowledgement message' which ONIX data recipients can send back to the original sender in response to receipt of an ONIX message, to confirm receipt and processing of the data. This is as yet not widely implemented, but can help make the exchange of ONIX data a more predictable and robust process, by providing a ‘feedback’ mechanism through which you can monitor the receipt and processing of the ONIX messages you send.

Where can I get more information about implementing ONIX?

EDItEUR has an e-mail list on as an announcement channel and implementation discussion forum for those working with ONIX for Books. Implementation questions are routinely discussed, and notices of ONIX developments are sent out to the list as well as to national groups.

The home page of the ONIX discussion forum is at and you can subscribe to the forum by sending a blank e-mail to

Is ONIX training available?

EDItEUR provides high-quality and authoritative face-to-face and online in-house training programmes to its members at a reasonable cost. If you are interested in receiving training – or reselling EDItEUR’s training to others – please contact EDItEUR. Some national user groups and other organizations also provide implementation help, workshops and formal training.

Terms & Conditions  |  Privacy Policy  |  Cookie Policy