The Malaysian MyKad (Kad Pengenalan) is the national identity document issued to citizens and permanent residents by the Jabatan Pendaftaran Negara (JPN). Its 12-digit IC number is not random — every digit carries a specific meaning under a fixed layout that has been stable for decades. This validator checks all four segments of that layout against the documented rules, explains each result in plain English and decodes the birth date, state and gender embedded in the number. Everything runs locally in your browser; the number is never transmitted anywhere.
How the MyKad number is structured
The format is written as YYMMDD-PB-###G and contains exactly 12 decimal digits:
| Segment | Digits | Meaning |
|---|---|---|
| YYMMDD | 1-6 | Date of birth: year (2 digits), month (01-12), day (01-31) |
| PB | 7-8 | Place-of-birth code (state or foreign-born category) |
| ### | 9-11 | Sequential serial within that date + state group |
| G | 12 | Gender digit — odd = Male, even = Female |
The MyKad has no checksum digit, which is why validation is structural: the validator can confirm the date is a real calendar date, the place-of-birth code is in the official JPN table, and the serial is not the reserved value 000 — but it cannot mathematically verify the number as a whole the way a checksum algorithm would.
Validation rules explained
Date of birth (YYMMDD). Month must be 01-12. Day must be between 01 and the correct number of days in that month — February is capped at 29 in leap years, 28 otherwise; the four 30-day months (April, June, September, November) are capped at 30. The year is encoded as two digits: the tool infers the century by comparing the encoded value to the current year’s last two digits, matching JPN’s issuance convention (values ≤ current 2-digit year map to 2000s, values above map to 1900s).
Place-of-birth code (PB). JPN assigns a specific two-digit code to each state and federal territory plus a range for people born abroad or registered under special circumstances. Single-digit state codes are zero-padded (Johor = 01; Kedah = 02; Perak = 08 etc.). Several codes can map to the same state, reflecting historical expansions to the code table as the state registrar absorbed more volume. The validator cross-references the code against the full published set and flags any value not in the official list.
Sequential serial (###). These three digits form a sequence number within the combination of date and place-of-birth code. They run from 001 to 999. The value 000 is explicitly reserved and never issued. The validator accepts any value from 001 to 999 and rejects 000.
Gender digit (G). The final digit encodes sex at the time of registration: any odd digit (1, 3, 5, 7, 9) means Male; any even digit (0, 2, 4, 6, 8) means Female. All single-decimal values are structurally valid digits so this rule never produces a format failure — it is informational only.
Worked example
Consider the obviously-fictitious number 900101-14-5571:
- 90-01-01 → year 90, inferred as 1990; month 01 (January); day 01 — a valid date (1 January 1990).
- 14 → W.P. Kuala Lumpur, a recognised JPN code.
- 557 → serial 557, well within 001-999.
- 1 → gender digit 1 (odd) → Male.
Result: structurally valid. All four rules pass.
Now consider 901301-14-5571 — the only change is the month segment is 13, which does not exist. The date-of-birth check fails immediately and the number is invalid. Similarly, 900229-14-5571 would fail in a non-leap year (1990 is not a leap year, so February 1990 had only 28 days), but 920229-14-5571 passes because 1992 is a leap year.
Why no checksum?
Many national ID systems add a check digit so any single typo in the number produces an invalid checksum (India’s Aadhaar uses Verhoeff; South Korea’s RRN uses a weighted modulus; the UK’s National Insurance number uses a letter encoding). The Malaysian NRIC was designed before check-digit techniques became standard practice for national registries, and JPN has not retrofitted one. The practical implication is that a one-digit transposition error can still produce a number that passes all structural checks — the format rules reduce the false-positive space (a bad month or an unknown PB code will still be caught) but cannot eliminate it entirely.
Where structural validation is actually used
Form validation in Malaysian services. Banks, telcos, insurers, and e-government portals ask for the IC number constantly; a structural check at the input field catches typos before a costly downstream lookup. Because there is no checksum, this front-line check is the only client-side defence against transcription errors.
KYC and onboarding pipelines. Compliance teams use structural validation as a cheap first gate: a number that fails here needs no manual review at all. Numbers that pass still require verification against official records or sighting of the physical card — the MyKad chip itself carries cryptographic data that the printed number does not.
Data cleaning. Legacy databases full of IC numbers accumulate entries with impossible dates (month 13, 31 February) and unknown state codes. Batch-validating against these rules is the standard way to quarantine bad rows before migration.
What it must never be used for: proving identity. A structurally valid number is trivially easy to fabricate precisely because the format is public and checksum-free. Treat validation as error-detection, not authentication.
Privacy note
An IC number reveals date of birth, birth state, and gender by design — it is personal data under Malaysia’s Personal Data Protection Act 2010. This validator runs entirely in your browser: the number you type is never transmitted, logged, or stored, which is the appropriate way to handle PDPA-scoped identifiers in a public tool.