EAN-13 and UPC-A Check Digits Explained: Build a Barcode Validator in JavaScript

A barcode can look perfectly valid and still encode an invalid number.

That is because retail barcode formats such as EAN-13 and UPC-A do more than render black bars.

They also include a check digit.

The check digit helps detect common mistakes in the numeric identifier.

Once you understand the algorithm, you can build a validator in a few lines of JavaScript.

What a check digit does

A check digit does not encrypt the number.

It does not prove that a product exists.

It does not tell you who owns the barcode.

It is a small integrity check.

GS1 describes the final digit of a barcode number as a check digit used to make sure the number is correctly composed.

Official reference:

GS1 Check Digit Calculator

EAN-13 structure

EAN-13 contains 13 digits.

Conceptually:

12 data digits
+ 1 check digit
= 13 digits

Example:

4006381333931

Here:

400638133393

is the first 12 digits.

The final:

1

is the check digit.

Let's calculate it.

EAN-13 check digit algorithm

Take the first 12 digits.

Starting from the left:

• multiply digits in odd positions by 1
• multiply digits in even positions by 3
• add the results
• find what digit must be added to reach the next multiple of 10

Using:

4 0 0 6 3 8 1 3 3 3 9 3

Weights:

1 3 1 3 1 3 1 3 1 3 1 3

Multiply:

4×1 = 4
0×3 = 0
0×1 = 0
6×3 = 18
3×1 = 3
8×3 = 24
1×1 = 1
3×3 = 9
3×1 = 3
3×3 = 9
9×1 = 9
3×3 = 9

Sum:

4 + 0 + 0 + 18
+ 3 + 24 + 1 + 9
+ 3 + 9 + 9 + 9
= 89

We need the next multiple of 10:

90

So:

90 - 89 = 1

Check digit:

1

Full EAN-13:

4006381333931

A clean JavaScript implementation

function ean13CheckDigit(
  first12
) {
  if (!/^\d{12}$/.test(first12)) {
    throw new Error(
      "EAN-13 payload must be 12 digits"
    );
  }

  const sum =
    [...first12]
      .map(Number)
      .reduce(
        (total, digit, index) => {
          const weight =
            index % 2 === 0
              ? 1
              : 3;

          return (
            total +
            digit * weight
          );
        },
        0
      );

  return (
    10 - (sum % 10)
  ) % 10;
}

Test it:

console.log(
  ean13CheckDigit(
    "400638133393"
  )
);

// 1

Generate a complete EAN-13 number

function completeEan13(first12) {
  const checkDigit =
    ean13CheckDigit(first12);

  return (
    first12 +
    checkDigit
  );
}

console.log(
  completeEan13(
    "400638133393"
  )
);

// 4006381333931

Validate an existing EAN-13

function isValidEan13(value) {
  if (!/^\d{13}$/.test(value)) {
    return false;
  }

  const payload =
    value.slice(0, 12);

  const expected =
    ean13CheckDigit(payload);

  const actual =
    Number(value[12]);

  return expected === actual;
}

Test:

console.log(
  isValidEan13(
    "4006381333931"
  )
);

// true

A more generic Mod-10 function

EAN/UPC families use related Mod-10 weighting logic.

You can write a generic helper:

function calculateGs1CheckDigit(
  payload
) {
  if (!/^\d+$/.test(payload)) {
    throw new Error(
      "Payload must contain digits only"
    );
  }

  const digits =
    [...payload]
      .map(Number)
      .reverse();

  const sum =
    digits.reduce(
      (total, digit, index) => {
        const weight =
          index % 2 === 0
            ? 3
            : 1;

        return (
          total +
          digit * weight
        );
      },
      0
    );

  return (
    10 - (sum % 10)
  ) % 10;
}

The reverse-first approach makes it easier to reason from the rightmost payload digit.

For EAN-13, pass the 12 data digits.

For UPC-A, pass the 11 data digits.

UPC-A example

UPC-A is commonly represented as:

11 data digits
+ 1 check digit
= 12 digits

So:

function completeUpcA(first11) {
  if (!/^\d{11}$/.test(first11)) {
    throw new Error(
      "UPC-A payload must be 11 digits"
    );
  }

  return (
    first11 +
    calculateGs1CheckDigit(
      first11
    )
  );
}

Validation:

function isValidUpcA(value) {
  if (!/^\d{12}$/.test(value)) {
    return false;
  }

  const payload =
    value.slice(0, 11);

  const expected =
    calculateGs1CheckDigit(
      payload
    );

  return (
    expected ===
    Number(value[11])
  );
}

Why modulo 10?

The check digit is chosen so the weighted total plus the check digit ends on a multiple of 10.

If:

sum % 10 = 0

then the check digit is:

0

That is why the formula is usually written:

(10 - (sum % 10)) % 10

The second % 10 handles the case where the sum is already divisible by 10.

Without it:

10 - 0 = 10

which is not a valid single digit.

Check digits are validation, not uniqueness

This is an important distinction.

Suppose your function says:

isValidEan13("...") === true

That only means:

the number passes the mathematical check-digit rule.

It does not automatically mean:

• the number was licensed correctly
• the product exists
• the manufacturer matches
• the identifier is currently assigned
• a marketplace will accept it

For real GS1 identity verification, use appropriate GS1 services and rules.

Barcode data vs barcode image

Another common confusion:

valid number
≠
valid barcode image

Once the data is correct, you still have to render the symbol correctly.

That includes things such as:

• bar pattern
• quiet zones
• dimensions
• readable contrast
• correct human-readable text
• print scaling

So there are really two layers:

Layer 1:
identifier validation

Layer 2:
barcode rendering

This article is primarily about Layer 1.

Why this matters in e-commerce tooling

If you process hundreds of products from a spreadsheet, it is much better to catch invalid identifiers before creating hundreds of barcode images.

A useful workflow:

CSV / Excel
    ↓
validate values
    ↓
calculate missing check digits
    ↓
flag invalid rows
    ↓
render barcode images
    ↓
download

Validation belongs before rendering.

Batch generation adds product-level complexity

Generating one barcode is easy.

Generating 500 introduces new concerns:

• filenames
• duplicate values
• invalid rows
• format selection
• progress
• ZIP packaging
• spreadsheet mapping
• error reporting

That is why a barcode generator quickly becomes a workflow tool.

I built these kinds of operational flows into BatchSet's Barcode Generator.

The current tool supports formats including:

• EAN-13
• UPC-A
• EAN-8
• UPC-E
• Code 128

and handles check digits for the relevant retail formats exposed in the interface.

If you need the actual scannable output rather than only the checksum code:

Generate a barcode with BatchSet

Useful test cases

Do not test only valid inputs.

const cases = [
  "",
  "123",
  "abcdefghijkl",
  "400638133393",
  "000000000000",
  "999999999999"
];

for (const value of cases) {
  try {
    console.log(
      value,
      ean13CheckDigit(value)
    );
  } catch (error) {
    console.log(
      value,
      error.message
    );
  }
}

Also test validation with:

correct check digit
incorrect check digit
leading zeros
non-digit input
too few digits
too many digits

Leading zeros are especially important because barcode identifiers are strings, not ordinary numbers.

Do not do this:

Number("012345678901")

if preserving the exact identifier matters.

Keep the value as a string.

Final takeaway

A retail barcode is not just black lines.

Before you render anything, validate the identifier.

For EAN-13 and UPC-A, the check-digit algorithm is small enough to understand and implement directly:

weighted sum
→ modulo 10
→ final check digit

That little validation step can prevent a surprising amount of bad data from moving deeper into an e-commerce or inventory workflow.