Elige el país
Cada país tiene su longitud: 16 caracteres en Bélgica, 24 en España, 29 en Brasil. Elige uno o deja que se mezclen para probar tu formulario con varias longitudes seguidas.
Cuentas IBAN de once países con los dos dígitos de control que calcula el módulo 97 y la longitud exacta de cada uno. En grupos de cuatro o sin espacios, válidos o deliberadamente rotos.
100 % privado. No hay servidor: los datos se generan en tu navegador y no se envían ni se guardan en ninguna parte.
Cómo funciona
Cada país tiene su longitud: 16 caracteres en Bélgica, 24 en España, 29 en Brasil. Elige uno o deja que se mezclen para probar tu formulario con varias longitudes seguidas.
El modo válido calcula los dos dígitos con el módulo 97. El inválido los altera: el IBAN parece perfecto y solo lo detecta una validación de verdad.
El CSV incluye el IBAN con y sin espacios, el país, los dígitos de control y la longitud. Listo para una carga masiva o para un fichero de pruebas.
Los dos dígitos que van justo después del código de país no son un número de serie: son un control matemático definido por la norma ISO 7064 en su variante MOD 97-10. El procedimiento es curioso y muy elegante:
A = 10, B = 11, hasta Z = 35.function ibanValido(iban) {
const s = iban.replace(/\s+/g, "").toUpperCase();
if (!/^[A-Z]{2}\d{2}[A-Z0-9]{10,30}$/.test(s)) return false;
const movido = s.slice(4) + s.slice(0, 4);
let resto = 0;
for (const ch of movido) {
const v = /\d/.test(ch) ? ch : String(ch.charCodeAt(0) - 55);
for (const d of v) resto = (resto * 10 + Number(d)) % 97; // resto acumulado
}
return resto === 1;
}
ibanValido("GB82 WEST 1234 5698 7654 32") // true ← ejemplo de la norma
ibanValido("GB83 WEST 1234 5698 7654 32") // false ← un dígito cambiado
El detalle del resto acumulado del bucle interno no es un adorno: un IBAN de treinta caracteres convertido a dígitos supera con mucho el entero exacto de JavaScript, y calcularlo de golpe daría un resultado incorrecto sin avisar. Dividiendo poco a poco, el cálculo es exacto para cualquier longitud.
La virtud de este control es que detecta el 99,99 % de los errores de tecleo: un dígito cambiado, dos cifras intercambiadas, un bloque desordenado. Por eso la norma lo eligió, y por eso un formulario de pago que no lo comprueba está dejando pasar errores que podría atrapar con siete líneas de código.
| Qué identifica | Ejemplo | |
|---|---|---|
| IBAN | La cuenta, de forma única en el mundo | ES91 2100 0418 4502 0005 1332 |
| BIC o SWIFT | El banco, no la cuenta. 8 u 11 caracteres | CAIXESBBXXX |
| Número de cuenta | La cuenta dentro de su banco | Formato propio de cada entidad |
Es un punto de confusión habitual en formularios: se pide «IBAN o SWIFT» como si fueran alternativas, cuando identifican cosas distintas. Dentro de la zona SEPA basta el IBAN; fuera, suelen pedirse los dos. Esta herramienta genera IBAN, no BIC, porque el BIC es un código asignado a entidades reales y no tiene sentido inventarlo.
Aquí está el error que aparece en cuanto una aplicación cruza una frontera: asumir la longitud del país propio. Un formulario español que valida exactamente 24 caracteres rechaza a un cliente belga, cuyo IBAN tiene 16, y a uno brasileño, que tiene 29. Y al revés.
Hay una segunda trampa relacionada: varios países admiten letras dentro del número de cuenta. Reino Unido lleva cuatro letras que identifican al banco, Países Bajos también, y Francia, Suiza, Italia y Brasil mezclan letras y dígitos. Si tu campo solo acepta cifras después del código de país, has excluido a seis de los once países que genera esta herramienta.
La prueba correcta es simple: elige «aleatorio» en el país, genera veinte IBAN y pásalos todos por tu formulario. Si alguno se cae, ahí tienes el fallo. La tabla completa de longitudes está en la página de generadores universales.
es91 2100… es lo que llega de un correo. Pasa a mayúsculas antes de comparar.Estos IBAN pasan el control del módulo 97, que es lo que comprueba cualquier formulario, pero no corresponden a ninguna cuenta abierta en ningún banco. No sirven para cobrar ni para pagar, y una orden SEPA con uno de ellos será rechazada por la entidad. Están para probar tu software.
Si trabajas con cuentas peruanas, el equivalente local es el Código de Cuenta Interbancario, que tiene su propia estructura de veinte dígitos.
Preguntas frecuentes
No. Los dígitos de control son correctos y cualquier validador lo acepta como IBAN bien formado, pero no existe ninguna cuenta detrás. No sirve para enviar ni recibir dinero.
Sí. Se calculan con ISO 7064 MOD 97-10, el algoritmo de la norma, verificado con el ejemplo canónico GB82WEST12345698765432. Cualquier validador de IBAN aceptará los que genera esta herramienta.
Once: España, Italia, Alemania, Francia, Reino Unido, Portugal, Países Bajos, Bélgica, Suiza, Austria y Brasil. Están elegidos para cubrir el rango de longitudes que más problemas causa, de 16 a 29 caracteres.
Para validar el formato del fichero, sí: los IBAN pasarán las comprobaciones de estructura y de control. Para probar el cobro de principio a fin necesitas el entorno de pruebas de tu banco o de tu pasarela, con las cuentas que ellos te asignen.
Casi siempre por asumir la longitud del país propio, o por no aceptar letras dentro del número de cuenta. Genera IBAN de varios países seguidos y lo verás enseguida: es el fallo más frecuente en este campo.
No. El BIC identifica a un banco real y está asignado por SWIFT, así que inventarlo no tendría sentido: no coincidiría con ninguna entidad. Esta herramienta genera IBAN, que es lo que se valida matemáticamente.
Sigue probando