piapia123
es

Verificador de números

Consultas

Todo se ejecuta en tu navegador: no se sube nada

Entrada
Arrastra un archivo aquí para cargarlo
Resultado

Los números de tarjeta, los IBAN, los ISBN y las direcciones BTC / ETH comparten una propiedad: los últimos dígitos existen para comprobar los anteriores. Así que «¿se copió bien este número?» tiene una respuesta definida: no hace falta red, ni saber de qué banco es. Hacerlo a mano es de verdad difícil: Luhn dobla un dígito sí y otro no y reduce los resultados de dos cifras, el IBAN convierte letras en números y calcula el módulo 97, una dirección de Bitcoin necesita dos rondas de SHA-256 y una de Ethereum necesita Keccak-256 (no SHA3-256: solo se diferencian en el primer byte de relleno y producen un resultado por completo distinto). ⚠️ Que el dígito de control pase no significa que el número exista. El dígito de control frena errores de tecleo (un dígito de menos, dos dígitos cambiados de orden), no verifica autenticidad: quien se inventa un número de tarjeta también calcula bien el dígito de Luhn. Aquí solo se responde «¿se copió bien esta cadena?».

Funciones

  • ⚠️ La primera línea ya avisa de que un dígito de control correcto no implica que el número exista, y cada veredicto dice «el dígito de control pasa», nunca «válido»
  • Los dos algoritmos Damm y Verhoeff (opcionales): frenan transposiciones contiguas que Luhn deja pasar
  • Documento de identidad chino (ISO 7064 MOD 11-2, con X como último carácter)
  • Validación del formato de IVA de la UE, los 27 Estados miembros; ⚠️ solo el formato, no si el número existe
  • Tarjetas: dígito de control Luhn y la red emisora por el rango IIN, con aviso aparte si el rango y la longitud no concuerdan
  • IBAN: ISO 7064 MOD 97-10, admite espacios y minúsculas; maneja longitudes distintas por país (Noruega 15, Malta 31)
  • ISBN-10 (con X como 10), ISBN-13 / EAN-13 y UPC-A, y señala que el prefijo 978/979 es un libro
  • Número de ruta ABA (ponderación 3-7-1), con la nota de que pasar solo significa cumplir el algoritmo, no que exista un banco real
  • BIC / SWIFT: solo se comprueba el formato — no tiene dígito de control, y el veredicto lo dice
  • Direcciones de Bitcoin clasificadas en cuatro tipos: Legacy (`1`, P2PKH), P2SH (`3`, multifirma / SegWit anidado), SegWit v0 (`bc1q`) y Taproot (`bc1p`), con el aviso de que no son intercambiables
  • Se prueban las dos constantes de Bitcoin, Bech32 y Bech32m, y se dice cuál encajó; una dirección con buen aspecto pero el checksum roto se marca como no válida
  • Ethereum: checksum EIP-55 por mayúsculas y minúsculas con Keccak-256; si es todo minúsculas o todo mayúsculas se dice «no se puede comprobar», nunca «no pasa»
  • ⚠️ Una misma entrada puede pertenecer a varios sistemas (los números de 9 y de 13 cifras, por ejemplo), así que el resultado es una lista, no un veredicto único
  • Pega varias líneas y se agrupan por línea

Cómo se usa

  1. Pega los números que quieras comprobar, uno por línea
  2. Lee la línea de conclusión: pasa / no pasa / solo formato / no se puede comprobar
  3. Lee la línea de base para ver con qué algoritmo se decidió

Preguntas frecuentes

¿Que pase significa que el número de tarjeta es real?
No. El dígito de control frena los errores de tecleo: un dígito de menos, dos dígitos cambiados de orden, una tecla equivocada; Luhn detecta unos nueve de cada diez. Contra la invención no hace nada: quien se inventa un número de tarjeta calcula bien el dígito de Luhn, que es una división. Así que «pasa» solo significa «no hay un error de copia evidente», y no dice nada sobre si la tarjeta existe, de quién es o si funciona.
¿Por qué Ethereum usa Keccak-256 y no SHA3-256?
Porque Ethereum es anterior al estándar SHA-3. Solo se diferencian en el primer byte de relleno (el Keccak original usa `0x01`, el SHA-3 del NIST usa `0x06`) y producen una salida por completo distinta. Calcular el checksum EIP-55 con SHA3-256 hace que todas las direcciones correctas fallen, y como los dos parecen «un hash», no hay ningún error visible. Las tres direcciones de ejemplo de la especificación EIP-55 fijan esto en las pruebas.
¿Por qué una dirección de Ethereum toda en minúsculas «no se puede comprobar»?
Porque el checksum EIP-55 va en las mayúsculas y minúsculas: tras calcular Keccak-256, si el dígito hexadecimal correspondiente es 8 o más, ese carácter de la dirección se pone en mayúscula. Así que una dirección toda en minúsculas o toda en mayúsculas no lleva ninguna información de checksum, y ambas formas eran legales antes de EIP-55, con muchas herramientas emitiéndolas todavía. Decir «no pasa» haría pensar que la dirección está mal; «no se puede comprobar» es la verdad.
¿Por qué el BIC solo da «formato correcto»?
Porque el BIC no tiene dígito de control. Son cuatro caracteres de entidad, dos de país, dos de localidad y tres opcionales de sucursal: todo alfanumérico de tabla, sin nada para autoverificarse. Así que la herramienta comprueba la longitud y que el código de país sean letras, pero no si el código existe; el veredicto lo dice, para que «formato correcto» no se tome por «verificado».
¿Qué significan los prefijos `1`, `3`, `bc1q` y `bc1p` de las direcciones de Bitcoin? ¿Se pueden mezclar?
Son cuatro generaciones de formato de dirección, con firma distinta e incompatibles entre sí. `1` es Legacy (P2PKH), la más antigua; `3` es P2SH (hash de script, habitual en multifirma y SegWit anidado); `bc1q` es SegWit v0 (P2WPKH / P2WSH); `bc1p` es Taproot (SegWit v1). Cada una pasa su propio checksum: las dos Base58 por el byte de versión (`0x00` / `0x05`) más un checksum de cuatro bytes con doble SHA-256, y las dos bech32 por el checksum Bech32 / Bech32m (idénticos salvo la constante del XOR final). ⚠️ No se pueden mezclar: entregar una dirección `1` o `3` a un exchange que solo acepta bech32 la rechaza sin más, y al revés igual; usa la generación que admita quien va a recibir.

Herramientas relacionadas