Validating CURP and RFC Entirely in the Browser: Structure, Check Digits, and Why No Server Is Needed

Portal Fone — Mon, 26 Oct 2026 11:11:23 GMT

Mexico's CURP and RFC identifiers look like random strings, but both carry internal structure that can be checked without ever sending them to a server. That matters: teachers paste these identifiers into payroll portals, and a single mistyped character blocks access. A client-side check catches the typo before any login attempt — and, because nothing leaves the device, there is no identifier to leak, log, or breach.

What the structure actually encodes

A CURP is 18 characters: initials from name data, birth date, sex, state code, a disambiguator, and a final verifier digit. An RFC for a person is 13 characters (10 for a company) with a similar pattern plus a homoclave. The check is not "does this string look right" — it is a sequence of small, testable rules:

Length and character set. Each position allows only certain characters (letters vs digits). Rejecting early, with the exact position, beats a generic "invalid" message.
Date plausibility. The embedded birth-date segment must be a real calendar date, not just six digits.
State and category codes. The state segment must be one of the real two-letter codes; an invented code fails here even if the rest parses.
Verifier digit. Both identifiers end in a check digit computed from the preceding characters. Recomputing it client-side catches transpositions that pass a regex — the most common real-world typo.

Why client-side, specifically

A server-side validator would need to receive the identifier, which creates a data-handling obligation for a string that functions as a personal key. Doing the same arithmetic in JavaScript removes that obligation entirely: the page works offline once loaded, returns an answer instantly, and has nothing to store. The trade-off is honest too: structure validation proves format, not existence. A well-formed CURP is not proof that a person is registered — only the official registry can say that, and a good validator says so in plain language instead of implying otherwise.

Testing without real identifiers

Test cases must never use real people's identifiers. The safe set is: a synthetically constructed valid example, one mutation per rule (wrong length, wrong character class, impossible date, bad state code, wrong verifier digit), and boundary cases such as leap-day dates. Each mutation should fail exactly one rule, so a regression points at the rule that broke, not at "validation" in general.

We built this as a small, dependency-free page — the live validator is at https://portalfone.com.mx/validador-curp-rfc/ — and the same discipline (one rule, one test, one clear error) is what we applied when turning the official pay calendar into a single canonical page: https://portalfone.com.mx/calendario-pagos-sep-2026/

Disclosure: I am part of PortalFone, the independent guide linked above. PortalFone is not an official SEP website; the validator checks format only and does not query any government registry.