Validador de RFC, CURP, CLABE y NSS
Comprueba si un RFC, CURP, CLABE o NSS es correcto. Detecta el tipo solo, verifica el dígito verificador y desglosa cada parte de la clave. Todo en tu navegador.
Escribe o pega una clave para analizarla.
Todo se valida en tu navegador. La clave no se envía ni se guarda en ningún servidor.
Se comprueban formato y dígito verificador. Esto no consulta al SAT, RENAPO ni al IMSS, así que no confirma que la clave esté dada de alta ni a quién pertenece.
Qué hace esta herramienta
Pegas una clave mexicana —RFC, CURP, CLABE o NSS— y te dice si está bien formada, qué tipo es y qué significa cada trozo. No hace falta que elijas el tipo: lo deduce de la forma de la cadena, aunque puedes forzarlo si quieres comprobar por qué algo no pasa como CURP.
La comprobación clave es el dígito verificador. Las cuatro claves lo llevan, y es lo que distingue una errata de captura de un valor legítimo. Todo el cálculo ocurre en tu navegador: la clave no viaja a ningún servidor.
Lo que sí comprueba y lo que no
Esta distinción es la que más problemas evita, así que conviene dejarla clara desde el principio:
| Comprobación | ¿Se hace aquí? |
|---|---|
| Longitud y estructura (orden de letras y dígitos) | Sí |
| Dígito verificador | Sí |
| Que la fecha embebida exista en el calendario | Sí |
| Clave de entidad federativa en el catálogo (CURP) | Sí |
| Banco emisor a partir del prefijo (CLABE) | Sí |
| Que la clave esté dada de alta en el SAT / RENAPO / IMSS | No |
| A quién pertenece la clave | No |
| Que la cuenta bancaria exista o esté activa | No |
Dicho de otro modo: un RFC inventado con el dígito correcto pasará esta validación. Eso es exactamente lo que necesitas para validar un formulario, pero no sustituye una consulta al padrón.
Cómo funciona cada dígito verificador
RFC — módulo 11
Se toman los doce caracteres previos al dígito, rellenando con un espacio a la izquierda cuando es persona moral (que solo tiene once). Cada carácter se traduce a número con una tabla donde 0-9 valen su cifra, A vale 10 y así hasta Z en 36, con el & ocupando el hueco 24 y el espacio el 37. Se multiplica cada valor por su posición —de 13 a 2—, se suman y se saca el residuo entre 11:
- residuo 0 → el dígito es
0 - residuo 1 → el dígito es
A - cualquier otro → el dígito es
11 − residuo
Con GODE561231GR la suma da 1026, que entre 11 deja residuo 3. Y 11 − 3 = 8, de ahí GODE561231GR8.
CURP — base 37, módulo 10
Los 17 primeros caracteres se traducen con un diccionario de 37 símbolos, se multiplican por pesos descendentes de 18 a 2, se suman y el dígito es el complemento a 10 del residuo.
CLABE — pesos 3-7-1
Los 17 primeros dígitos se multiplican por 3, 7 y 1 en ciclo. De cada producto se queda la unidad, es decir, el producto módulo 10: un 63 aporta 3. El error típico es copiar Luhn y sumar las cifras del producto, con lo que ese 63 aporta 6 + 3 = 9; con 09000000000000000 el algoritmo correcto da 7 y la versión estilo Luhn da 1. El dígito de control es el complemento a 10 de la suma (si la suma termina en 0, el dígito es 0).
NSS — Luhn
El mismo algoritmo que valida las tarjetas de crédito, aplicado a los diez primeros dígitos.
Errores que aparecen todo el tiempo
Los RFC genéricos. XAXX010101000 (público en general) y XEXX010101000 (residentes en el extranjero) se asignaron por decreto. El de público en general no cumple el algoritmo: el módulo 11 pide un 4 y el SAT puso un 0, así que cualquier validador escrito a mano lo rechaza, y ahí es donde se rompe la facturación al público en general. El de residentes en el extranjero sí lo cumple, pero por casualidad: un validador que solo mire el dígito lo acepta como persona física nacida el 1 de enero de 2001. Esta herramienta reconoce los dos antes de aplicar el algoritmo y los marca como RFC genérico.
La O y el cero. En un RFC las posiciones están tipadas: donde va fecha van dígitos, y la letra O en esa zona es siempre una errata.
El siglo de la CURP. El año va en dos cifras, y quien asume «menor que 30 → 2000s» se equivoca. El siglo está en la posición 17: dígito para nacimientos anteriores al 2000, letra a partir de 2000.
La Ñ y los acentos. No aparecen: la Ñ se sustituye por X y los acentos se ignoran al formar la clave.
Herramientas relacionadas
- Generador de datos de prueba de México — el camino inverso: crea RFC, CURP, CLABE y NSS ficticios que pasan esta misma validación.
- Generador de datos de prueba — datos sintéticos genéricos, sin claves mexicanas.
Preguntas frecuentes
¿Esto confirma que el RFC o la CURP están dados de alta?
No, y es la distinción que más importa. La herramienta comprueba que la clave esté bien formada y que su dígito verificador cuadre con el resto de los caracteres, que es lo que necesitas para validar un formulario o un import de datos. No consulta al SAT, a RENAPO ni al IMSS, así que no puede decirte si esa clave existe en el padrón ni a quién pertenece. Un RFC inventado con el dígito correcto pasará esta validación; para confirmar el alta hay que ir a los servicios oficiales.
¿Cómo se calcula el dígito verificador del RFC?
Se toman los doce caracteres anteriores (rellenando con un espacio a la izquierda si es persona moral, que solo tiene once). Cada carácter se convierte a un número según una tabla donde 0-9 valen su cifra, la A vale 10 y así hasta la Z, con el «&» en el hueco 24. Cada valor se multiplica por su posición, de 13 a 2, se suman todos y se saca el residuo entre 11. Si el residuo es 0 el dígito es «0»; si es 1, es «A»; en cualquier otro caso es 11 menos el residuo. Por ejemplo, GODE561231GR suma 1026, que entre 11 deja residuo 3, y 11 − 3 = 8: por eso el RFC completo es GODE561231GR8.
¿Por qué me marca inválido un RFC que el SAT sí acepta?
La causa más frecuente son los RFC genéricos, que el SAT asignó por decreto. XAXX010101000 (público en general) no cumple el algoritmo del dígito verificador: el cálculo pide un 4 y lleva un 0. XEXX010101000 (residentes en el extranjero) sí lo cumple, pero por casualidad, y un validador que solo mire el dígito lo tomaría por una persona física nacida en 2001. Esta herramienta reconoce los dos antes de calcular nada y los da por válidos como RFC genérico, pero muchas implementaciones caseras no, y ahí es donde suele romperse la facturación. Si el que falla es otro RFC, revisa que no lleve la letra O donde va un cero: es el error de captura más común.
¿Qué significan las 18 posiciones de la CURP?
Las cuatro primeras salen del nombre: inicial del primer apellido, su primera vocal interna, inicial del segundo apellido e inicial del nombre de pila. Las seis siguientes son la fecha de nacimiento en AAMMDD. Luego va H, M o X para el sexo y dos letras de la entidad de nacimiento. Las tres siguientes son la primera consonante interna de cada uno de los tres nombres. La posición 17 es la homoclave, que además resuelve el siglo: un dígito si naciste antes del 2000 y una letra a partir de 2000. La 18 es el dígito verificador.
¿Qué comprueba exactamente en una CLABE?
Que tenga 18 dígitos y que el último cuadre con el algoritmo de Banxico: los primeros 17 se multiplican por los pesos 3, 7 y 1 en ciclo, de cada producto se toma la unidad (un 63 aporta 3, no 6 + 3 = 9 como haría una implementación que copia Luhn) y el dígito de control es el complemento a 10 de la suma. Además identifica el banco a partir de los tres primeros dígitos. Lo que no puede saber es si la cuenta existe o está activa: eso solo lo sabe el banco.
¿Se envía la clave a algún servidor?
No. Todo el cálculo ocurre en JavaScript dentro de tu navegador; no hay ninguna petición de red al escribir. Puedes comprobarlo abriendo la pestaña de red de las herramientas de desarrollo, o directamente desconectando internet: la herramienta sigue funcionando. Aun así, un RFC o una CURP son datos personales, así que evita pegarlos en sitios que no sepas cómo funcionan.
Reseñas y valoraciones
Aún no hay reseñas. ¡Sé la primera persona en opinar!
Guías relacionadas
Tutoriales del blog donde esta herramienta resulta útil.
Herramientas relacionadas
Otras del catálogo que se usan bien junto a esta.