Jump to content

Barcodes

From Open Food Facts wiki

Other languages:
/ français /

Barcode length

The majority of product codes are following EAN-13 standard, and, as such, are 13 chars length.

As of 2022-04-06, Open Food Facts contains more than 12,000 products (~0.5%) with a barcode longer than 13 chars.

Open Food Facts website can't display a product with a barcode longer than 24 chars (a bug is open).

Barcode normalization by the Open Food Facts server (productopener)

Barcode normalization by the Open Food Facts app (smooth-app)

  • TODO: WRITE ME

Implementing a great barcode scanning experience

Barcode weight

For EAN-13 barcodes, GS1 recommend barcodes' weight to be ~32mm. In general, producers tend to use barcodes between 24 and 35 mm. Values below 24mm and above 35 are rare.

Testing barcodes with our apps

It's interesting to control that our apps are playing well with different barcodes' size. We build a test document that you can print and use with the app.

Barcodes data quality

Sometimes we're not sure a barcode exists or not. Barcodes scanners are sometimes making mistakes.

The following site allows you to verify if a barcode exists or not: https://www.gs1.org/services/verified-by-gs1

Barcodes conflicts

Sometimes, scanning a barcode leads to a product not matching to the one we have in the hand. How is it possible?

A. Sometimes a product has been previously entered with a wrong barcode? That's rare but possible. In this case you can try to move the wrong product to the right one: ask moderators if you don't have the right to do so.

B. There is barcode conflict: two different products really share the same barcode. There are several reasons why this can happen:

  • some brands reuse old barcodes they have already used in the past
  • some brands create their own barcode, beginning by 2: then the chance to share a barcode with another brand is possible

Some brands use short barcodes, EAN 8, with 8 numbers: the chance to encounter barcodes conflicts is higher.

How to deal with barcode conflicts?

As of today (2025-02), there are no solution to deal with these conflicts.

That said, it's already possible to list these cases:

All things barcode

Barcode related pages on Open Food Facts

News

  • Wikidata is adding support for GS1 country prefixes

Roadmap

  • Features and bugs to work on
  • Channel on Slack: https://openfoodfacts.slack.com/archives/C21803P5W
  • Adding APIs for mobile scanning apps
  • Get country suggestions from a barcode
  • Get product type suggestions from a barcode (We might want to prefill all ISBNs as a OPF product type…)
  • Get Manufacturer Code suggestions
  • Get Product Code suggestions
  • Get barcode API
  • Generate barcode SVG from a barcode
  • Embed barcode utils in our SDKs
  • Finish adding support for the GS1 QRCodes
  • Add support for Amazon barcodes
  • Add support for barcode by weight, discount barcodes, Known ambiguous barcode, Known bad barcodes (1234567…, or ISBN)
  • Advocacy for API reusers on how to handle barcodes properly
  • Help recover gracefully from erroneous scans, while not suppressing barcodes that exist in real life but are not in the database

Beyond the barcode (and the QRCode): Prepare for a paradigm change

  • with Open Products Facts, and raw products, we need to move beyond the barcode, and have alternative ways to reliably identify a product (eg: brand, model name, country for smartphones, OR category, origin, organic status for veggies, or brand, product_name, country for the BigMac ?).
  • The new wave of AI nutrition apps is proposing photo >> response. The barcode is only one of the options for them. The new idea is use your camera (broadly), get a response. As opposed to scan the barcode, get a response.

See also