Mexican ID Validator — RFC, CURP, CLABE, NSS
Check whether an RFC, CURP, CLABE or NSS is correct. Detects the type on its own, verifies the check digit and breaks down every part of the ID. All in your browser.
What this tool does
You paste a Mexican ID — RFC, CURP, CLABE or NSS — and it tells you whether it is well formed, which type it is and what each part means. You do not have to pick the type: it infers it from the shape of the string, though you can force it if you want to see why something fails as a CURP.
The key check is the check digit. All four IDs carry one, and it is what separates a typo from a legitimate value. All the computation happens in your browser: the ID never travels to a server.
What it checks, and what it does not
This distinction avoids the most trouble, so it is worth stating up front:
| Check | Done here? |
|---|---|
| Length and structure (order of letters and digits) | Yes |
| Check digit | Yes |
| That the embedded date exists in the calendar | Yes |
| State code against the catalogue (CURP) | Yes |
| Issuing bank from the prefix (CLABE) | Yes |
| That the ID is registered with the SAT / RENAPO / IMSS | No |
| Who the ID belongs to | No |
| That the bank account exists or is active | No |
Put differently: a made-up RFC with the right check digit will pass this validation. That is exactly what you need to validate a form, but it does not replace a lookup against the official register.
How each check digit works
RFC — modulo 11
Take the twelve characters preceding the digit, padding with a leading space for companies (which only have eleven). Each character maps to a number through a table where 0-9 are their own value, A is 10 and so on up to Z at 36, with & occupying slot 24 and the space 37. Multiply each value by its position — from 13 down to 2 — sum them, and take the remainder modulo 11:
- remainder 0 → the digit is
0 - remainder 1 → the digit is
A - anything else → the digit is
11 − remainder
For GODE561231GR the sum is 1026, which leaves remainder 3 modulo 11. And 11 − 3 = 8, hence GODE561231GR8.
CURP — base 37, modulo 10
The first 17 characters are mapped through a 37-symbol dictionary, multiplied by descending weights from 18 to 2, summed, and the digit is the complement to 10 of the remainder.
CLABE — weights 3-7-1
The first 17 digits are multiplied by 3, 7 and 1 in a cycle. Each product is reduced modulo 10 before being added: that intermediate step is the one missing from almost every incorrect implementation floating around. The control digit is the complement to 10 of the sum.
NSS — Luhn
The same algorithm that validates credit cards, applied to the first ten digits.
Mistakes that come up constantly
The generic RFCs. XAXX010101000 (general public) and XEXX010101000 (foreign residents) were assigned by decree and do not satisfy the algorithm. Any hand-written validator rejects them, and that is precisely where general-public invoicing breaks. This tool recognises them as special cases.
Letter O versus zero. RFC positions are typed: where the date goes, digits go, and the letter O in that stretch is always a typo.
The CURP century. The year is two digits, and assuming “less than 30 → 2000s” is wrong. The century lives in position 17: a digit for births before 2000, a letter from 2000 onwards.
Ñ and accents. They never appear: Ñ is replaced by X and accents are ignored when forming the ID.
Related tools
- Mexican test data generator — the inverse: creates fictitious RFC, CURP, CLABE and NSS that pass this very validation.
- CFDI 4.0 XML viewer — validates issuer and recipient RFCs straight from an invoice.
- Mock data generator — generic synthetic data, without Mexican IDs.
Frequently asked questions
Does this confirm the RFC or CURP is actually registered?
No, and that is the distinction that matters most. The tool checks that the ID is well formed and that its check digit adds up against the rest of the characters, which is what you need to validate a form or a data import. It does not query the SAT, RENAPO or IMSS, so it cannot tell you whether the ID exists on the register or who it belongs to. A made-up RFC with the right check digit will pass this validation; to confirm registration you have to use the official services.
How is the RFC check digit calculated?
You take the preceding twelve characters (padding with a leading space for companies, which only have eleven). Each character maps to a number through a table where 0-9 are their own value, A is 10 and so on up to Z, with "&" sitting in slot 24. Each value is multiplied by its position, from 13 down to 2, the products are summed and the remainder modulo 11 is taken. If the remainder is 0 the digit is "0"; if it is 1, it is "A"; otherwise it is 11 minus the remainder. For example, GODE561231GR sums to 1026, which leaves remainder 3 modulo 11, and 11 − 3 = 8 — hence the full RFC GODE561231GR8.
Why does it flag an RFC the SAT accepts?
The usual culprit is the generic RFCs. XAXX010101000 (general public) and XEXX010101000 (foreign residents) were assigned by decree and do not satisfy the check digit algorithm. This tool recognises them and treats them as valid, but many home-grown implementations do not, and that is exactly where invoicing tends to break. If a different RFC is failing, check it does not carry the letter O where a zero belongs — the most common data-entry mistake.
What do the 18 positions of a CURP mean?
The first four come from the name: initial of the first surname, its first internal vowel, initial of the second surname and initial of the given name. The next six are the date of birth as YYMMDD. Then comes H, M or X for sex and two letters for the state of birth. The following three are the first internal consonant of each of the three names. Position 17 is the homoclave, which also resolves the century: a digit if you were born before 2000 and a letter from 2000 onwards. Position 18 is the check digit.
What exactly does it check on a CLABE?
That it has 18 digits and that the last one matches the Banxico algorithm: the first 17 are multiplied by the weights 3, 7 and 1 in a cycle, each product is reduced modulo 10 before summing — that intermediate step is what incorrect implementations tend to forget — and the control digit is the complement to 10 of the sum. It also identifies the bank from the first three digits. What it cannot know is whether the account exists or is active: only the bank knows that.
Is the ID sent to any server?
No. All the computation happens in JavaScript inside your browser; no network request fires as you type. You can confirm it by opening the network tab in your developer tools, or simply by going offline: the tool keeps working. Even so, an RFC or CURP is personal data, so avoid pasting them into sites whose behaviour you do not know.
Reviews & ratings
No reviews yet. Be the first to leave one!
Related tools
Others from the catalogue that pair well with this one.