DEV Community

Livi
Livi

Posted on

Vanilla JavaScript validators: the algorithms behind Spanish ID documents

Vanilla JavaScript validators: the algorithms behind Spanish ID documents

This article walks through the validation algorithms for Spanish identity documents (DNI, NIE, CIF) and their Iberoamerican counterparts (RFC, RUT, RUC, NIT, CUIT). All implementations are vanilla JavaScript with zero dependencies. They run client-side at haz.tools/c/validar.

Why these algorithms matter

Identity documents in Spanish-speaking countries embed mathematical structure to detect transcription errors. A single typo in a DNI almost always produces an invalid letter; the validator catches it instantly. Validating before submission prevents the most common error class in any form that captures these documents.

Most importantly, this validation does not require contacting any government API. The math is enough.

DNI (Spain)

const DNI_LETTERS = 'TRWAGMYFPDXBNJZSQVHLCKE';

export function validateDNI(input) {
  const match = input.toUpperCase().replace(/\s/g, '').match(/^([0-9]{8})([A-Z])$/);
  if (!match) return { valid: false, reason: 'format' };
  const number = parseInt(match[1], 10);
  const expected = DNI_LETTERS[number % 23];
  return {
    valid: match[2] === expected,
    expected,
    received: match[2]
  };
}
Enter fullscreen mode Exit fullscreen mode

The letter is not arbitrary. It is 'TRWAGMYFPDXBNJZSQVHLCKE'[number % 23]. The string has 23 characters. I, Ñ, O, U are intentionally excluded to avoid confusion with similar-looking digits and letters.

NIE (Spain — foreign residents)

const NIE_PREFIX = { X: '0', Y: '1', Z: '2' };

export function validateNIE(input) {
  const match = input.toUpperCase().replace(/\s/g, '').match(/^([XYZ])([0-9]{7})([A-Z])$/);
  if (!match) return { valid: false, reason: 'format' };
  const numberStr = NIE_PREFIX[match[1]] + match[2];
  const number = parseInt(numberStr, 10);
  const expected = DNI_LETTERS[number % 23];
  return { valid: match[3] === expected, expected, received: match[3] };
}
Enter fullscreen mode Exit fullscreen mode

Same modulo 23, but the leading letter is mapped to a digit first. NIE is the document issued to non-Spanish residents and to foreigners with tax obligations in Spain.

CIF (Spain — corporate)

const CIF_LETTERS = 'JABCDEFGHI';

export function validateCIF(input) {
  const match = input.toUpperCase().replace(/\s/g, '').match(/^([ABCDEFGHJKLMNPQRSUVW])([0-9]{7})([0-9A-J])$/);
  if (!match) return { valid: false, reason: 'format' };

  const [_, type, digits, control] = match;
  let evenSum = 0, oddSum = 0;

  for (let i = 0; i < digits.length; i++) {
    const d = parseInt(digits[i], 10);
    if (i % 2 === 0) {
      const doubled = d * 2;
      oddSum += Math.floor(doubled / 10) + (doubled % 10);
    } else {
      evenSum += d;
    }
  }

  const total = evenSum + oddSum;
  const controlDigit = (10 - (total % 10)) % 10;

  // Some entity types use a digit, others a letter
  const useLetterControl = 'KPQSNW'.includes(type);
  const expected = useLetterControl ? CIF_LETTERS[controlDigit] : controlDigit.toString();

  return { valid: control === expected, expected, received: control };
}
Enter fullscreen mode Exit fullscreen mode

The leading letter encodes entity type (A=SA, B=SL, etc.). The control character can be a digit or a letter depending on the type.

IBAN (módulo 97, ISO 13616)

export function validateIBAN(input) {
  const iban = input.toUpperCase().replace(/\s/g, '');
  if (!/^[A-Z]{2}[0-9]{2}[A-Z0-9]+$/.test(iban)) return false;

  const reordered = iban.slice(4) + iban.slice(0, 4);
  const numeric = reordered.replace(/[A-Z]/g, c =>
    (c.charCodeAt(0) - 55).toString()
  );

  let remainder = 0;
  for (const digit of numeric) {
    remainder = (remainder * 10 + parseInt(digit, 10)) % 97;
  }

  return remainder === 1;
}
Enter fullscreen mode Exit fullscreen mode

The block-by-block modulo is critical. The substituted IBAN exceeds Number.MAX_SAFE_INTEGER (2^53 - 1). A naive Number(numeric) % 97 returns wrong results for any Spanish IBAN.

Alternative: BigInt(numeric) % 97n === 1n. Cleaner but slightly slower. The block approach is faster and works in environments where BigInt is unavailable.

Live demo at haz.tools.

RFC (Mexico)

export function validateRFC(input) {
  // Persona física: 13 chars (4 letters + 6 digits + 3 chars)
  // Persona moral: 12 chars (3 letters + 6 digits + 3 chars)
  const rfc = input.toUpperCase().replace(/\s/g, '');
  return /^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$/.test(rfc);
}
Enter fullscreen mode Exit fullscreen mode

The 6 digits are the date in YYMMDD format. The last 3 characters are a homoclave assigned by SAT. There is no checksum to verify in pure form; structure validation is the maximum.

RUT (Chile, módulo 11)

export function validateRUT(input) {
  const cleaned = input.replace(/[.-]/g, '').toUpperCase();
  const match = cleaned.match(/^(\d+)([0-9K])$/);
  if (!match) return false;

  const [_, body, dv] = match;
  let sum = 0;
  let multiplier = 2;

  for (let i = body.length - 1; i >= 0; i--) {
    sum += parseInt(body[i], 10) * multiplier;
    multiplier = multiplier === 7 ? 2 : multiplier + 1;
  }

  const expected = 11 - (sum % 11);
  const expectedDV = expected === 11 ? '0' : expected === 10 ? 'K' : expected.toString();
  return dv === expectedDV;
}
Enter fullscreen mode Exit fullscreen mode

Chilean RUT uses módulo 11 with a digit verifier. The verifier can be a digit (0-9) or 'K' when the result is 10.

Credit cards (Luhn)

export function validateLuhn(input) {
  const digits = input.replace(/\D/g, '');
  if (digits.length < 12 || digits.length > 19) return false;

  let sum = 0;
  let alternate = false;

  for (let i = digits.length - 1; i >= 0; i--) {
    let n = parseInt(digits[i], 10);
    if (alternate) {
      n *= 2;
      if (n > 9) n -= 9;
    }
    sum += n;
    alternate = !alternate;
  }

  return sum % 10 === 0;
}
Enter fullscreen mode Exit fullscreen mode

Luhn detects almost all single-digit errors and most adjacent-digit transpositions. Combined with prefix-based network detection (Visa starts with 4, Mastercard with 51-55 or 2221-2720, Amex with 34/37, etc.) it covers credit card validation needs.

Production usage

All these validators ship in haz.tools/c/validar and run client-side. No data leaves the browser. The implementations above are essentially what is in production, modulo error formatting and edge case handling.

Other validators in the same family at haz.tools:

  • IBAN for SEPA countries
  • RUC (Peru), NIT (Colombia), CUIT (Argentina)
  • Email with MX record check
  • URL with structure validation
  • JSON Schema validator
  • Regex tester with match highlighting

The full directory has 100+ tools. If you need a validator that does not exist, request it: contacto@haz.tools.

Top comments (0)