J-Kit
Português

Test documents & IDs

CPF and CNPJ: the check digit, validation and the alphanumeric CNPJ

A CPF or CNPJ number that "passes validation" proves one thing only: that its last two digits match a modular-arithmetic sum. It does not prove the document exists, that it belongs to anyone, or that it is in good standing with the tax authority. Confusing "valid" with "true" is behind half of all registration bugs and nearly every misunderstanding about test-data generators. This guide opens the check digit to the bone, it is a mod-11 checksum, and you will compute it digit by digit, shows what validation cannot reach, and lands on the most current, most-searched part of the subject: the alphanumeric CNPJ that Brazil starts issuing in 2026. Paste numbers into the [CPF/CNPJ validator](tool:validador-cpf-cnpj) as you read; it runs the same algorithm, in your browser, sending nothing.

J-Kit15 min readIntermediate
  • CPF
  • CNPJ
  • Check digit
  • Alphanumeric CNPJ
  • Test data

Key takeaways

  • The check digit is a weighted mod-11 checksum: it catches typos, not existence. Valid ≠ existing ≠ in good standing.
  • CPF uses 9 base digits with weights 10..2 and 11..2; CNPJ uses 12 base digits with weights 5,4,3,2,9..2 and 6,5,4,3,2,9..2. Remainder below 2 → digit 0.
  • From 2026 Brazil issues the alphanumeric CNPJ: the first 12 positions may contain letters, the 2 check digits stay numeric, and the calculation uses each character’s ASCII value minus 48.
  • Generating synthetic CPF/CNPJ for tests is legitimate; using a real third party’s document is not (Brazil’s LGPD, Law 13.709/2018).

Valid, existing, in good standing: three different things

Before generating or validating any number, separate what each operation actually proves. Check-digit validation is local and cheap: it only confirms that the last two digits close the sum. Knowing whether the document exists requires the tax authority’s registry. Knowing whether it is in good standing, active, suspended, closed, is a registry lookup with its own access rules. These are three distinct questions, and the first never answers the other two.

Valid number

  • The check digits close by the mod-11 algorithm.
  • Proves only mathematical consistency, on your own machine.
  • A generator produces millions of them in seconds.

Existing document

  • Was issued and is assigned to a person or company.
  • Only the tax authority confirms it; you cannot infer it from the number.

Registry in good standing

  • Status (active, suspended, closed), name/company name, activity.
  • Requires an authorized source and a legitimate lookup purpose.

The gap between "valid" and "true" is the heart of this guide. A CPF generator and a CNPJ generator live entirely on the left side: they fabricate mathematically consistent numbers to fill test forms and seed staging databases. The CNPJ lookup lives on the right, and works only for companies, because the CNPJ is public, the CPF, being personal data, is protected. Understanding the border prevents both the bug ("why did the form accept a CPF that doesn’t exist?") and the abuse ("I generated a valid one, so I can use it").

11CPF digits (9 base + 2 check)
14CNPJ positions (12 base + 2 check)
mod 11the arithmetic behind the final two digits

The check digit is a mod-11 checksum

The check digit is neither a hash nor encryption, if the difference between those still trips you up, the hashing, encryption and encoding guide settles it. It is a checksum: an extra number, derived from the ones before it, whose only job is to catch typos and transpositions. The choice of modulo 11 is not arbitrary. Being prime, 11 catches more error types than a modulo 10 would: it flags any single-digit change and, by using increasing weights, most swaps of neighboring digits too, the classic "typed 21 instead of 12". It is the same principle behind the ISBN-10 control digit and many bank numbers.

S = Σ (dᵢ × pᵢ) → r = S mod 11 → DV = (r < 2) ? 0 : 11 − r
dᵢ
the i-th base digit (left to right)
pᵢ
the weight for that position (see table below)
S
the sum of all digit × weight products
r
the remainder of S divided by 11
DV
the resulting check digit (0 to 9)
The core of the algorithm, identical for CPF and CNPJ: only the weights change. Each base digit is multiplied by a weight, everything is summed, the remainder of the division by 11 is taken, and the check digit is 11 minus that remainder, with the exception that remainders 0 and 1 become digit 0.

The second check digit uses the exact same procedure, with one difference: it includes the first check digit, now known, in the base and shifts the weights by one place (CPF goes from 10..2 to 11..2; CNPJ, from 5,4,3,2,9..2 to 6,5,4,3,2,9..2). That is why the two digits are interdependent: changing the first changes the second. The weights below match exactly those of this platform’s CPF/CNPJ validator.

The weights for each check digit, read left to right, aligned with the base digits.
DocumentBase1st check-digit weights2nd check-digit weights
CPF9 digits10 9 8 7 6 5 4 3 211 10 9 8 7 6 5 4 3 2
CNPJ12 positions5 4 3 2 9 8 7 6 5 4 3 26 5 4 3 2 9 8 7 6 5 4 3 2

Note the CNPJ pattern: the weights are the sequence 2 through 9 read right to left, restarting at 2 after 9. The CPF is simpler still: a countdown starting at 10 (or 11, for the second digit). That regularity is what lets you write the calculation in a few lines, and what makes the extension to letters, coming up, almost painless.

Worked example: a CPF computed from scratch

Let us compute the two check digits of a didactic base: 111.444.777. It is a number used only to demonstrate the math, it represents nobody. We multiply each digit by its weight, sum, take the remainder mod 11 and apply the rule.

CPF base:  1  1  1  4  4  4  7  7  7   (os 9 primeiros dígitos)

1o digito verificador ,  pesos 10 9 8 7 6 5 4 3 2
  1x10 + 1x9 + 1x8 + 4x7 + 4x6 + 4x5 + 7x4 + 7x3 + 7x2
  =  10 + 9 + 8 + 28 + 24 + 20 + 28 + 21 + 14  =  162
  162 mod 11 = 8   ->   8 >= 2   ->   DV1 = 11 - 8 = 3

2o digito verificador ,  pesos 11 10 9 8 7 6 5 4 3 2  (inclui o DV1)
  base agora:  1  1  1  4  4  4  7  7  7  3
  1x11 + 1x10 + 1x9 + 4x8 + 4x7 + 4x6 + 7x5 + 7x4 + 7x3 + 3x2
  =  11 + 10 + 9 + 32 + 28 + 24 + 35 + 28 + 21 + 6  =  204
  204 mod 11 = 6   ->   6 >= 2   ->   DV2 = 11 - 6 = 5

CPF completo:  111.444.777-35   (fecha o modulo 11)
Full digit-by-digit calculation of the two CPF check digits. Paste 111.444.777-35 into the validator to check.

There is a detail hidden in the ninth digit, the last of the base, here the 7. It indicates the fiscal region where the CPF was issued, following the tax authority’s division into ten regional superintendencies. It is not where the person was born or lives today: it is the region of the address given at first registration. In our example, the 7 corresponds to ES and RJ.

The ninth CPF digit and the issuing fiscal region (ten regions of the tax authority; the 10th uses digit 0).
9th digitFiscal regionStates
11stDF, GO, MT, MS, TO
22ndAC, AM, AP, PA, RO, RR
33rdCE, MA, PI
44thAL, PB, PE, RN
55thBA, SE
66thMG
77thES, RJ
88thSP
99thPR, SC
010thRS

In other words: the CPF carries a weak hint of origin, but nothing more. It encodes no birth date, sex or any personal attribute, only the fiscal region and the two control digits. People validating forms often reinforce the digit check with a format mask built from regular expressions, making sure the text has the right shape before the arithmetic even runs.

The alphanumeric CNPJ: the 2026 change

This is the most current part of the subject. The numeric CNPJ has finite capacity, and the tax authority projects the combinations running out. The answer was Normative Instruction RFB No. 2,229, of 15 October 2024, which created the alphanumeric CNPJ. The format changes neither size nor mask: it stays 14 positions displayed as XX.XXX.XXX/XXXX-XX. What changes is the alphabet of the positions: the first 8 (the root) and the next 4 (the establishment order) may now hold uppercase letters A to Z in addition to digits. The last two positions, the check digits, remain strictly numeric.

  1. 1965–1968The CPF is born

    Law 4,862/1965 creates the individual taxpayer registry; Decree-Law 401/1968 turns it into the Cadastro de Pessoas Físicas, with the 11 digits we still use today.

  2. 1998CGC becomes CNPJ

    Normative Instruction SRF 27/1998 replaces the old Cadastro Geral de Contribuintes (CGC) with the CNPJ, keeping existing numbers and the 14-digit format.

  3. 15 Oct 2024IN RFB 2,229 creates the alphanumeric CNPJ

    The rule defines the new alphabet (letters in the first 12 positions, numeric check digits) and the ASCII-based digit calculation. Existing CNPJs do not change.

  4. 2026Go-live

    The validation rule accepting the alphanumeric CNPJ goes into production in the fiscal systems on 6 July 2026, and the tax authority starts issuing the new numbers from 31 July 2026.

Every developer’s question is: how do you compute the check digit if the base now has letters? The answer is elegant. Instead of treating each position as the digit it represents, you treat each character by its ASCII table value minus 48. The digits 0 to 9 have ASCII codes 48 to 57, so "0" still equals 0 and "9" still equals 9, nothing changes for old CNPJs. The letters A to Z have codes 65 to 90, so "A" equals 17, "B" equals 18, and so on up to "Z" equalling 42. With the characters converted to numbers, the calculation is identical to the numeric one: the same weights, the same modulo 11.

  1. Isolate the 12 base positionsThe root (8) and the order (4), which may contain A–Z and 0–9. The two check digits stay out of the calculation, since they are what you want to find.
  2. Convert each character to a numberUse the character’s ASCII code minus 48. Digits map to themselves (0–9); letters map to 17 (A) through 42 (Z).
  3. Multiply by the weights and sumThe same weights as the numeric CNPJ: 5,4,3,2,9,8,7,6,5,4,3,2 for the 1st check digit. Sum all products.
  4. Apply modulo 11Take the remainder of the sum by 11. If it is below 2, the check digit is 0; otherwise the check digit is 11 minus the remainder.
  5. Repeat for the second check digitAppend the 1st check digit (already numeric) to the base, forming 13 positions, and redo with weights 6,5,4,3,2,9,8,7,6,5,4,3,2. Both check digits always come out numeric.
CNPJ base (12 posicoes):  1  2  A  B  C  3  4  5  0  1  D  E

Passo 1 ,  cada caractere -> valor ASCII menos 48
  1->1   2->2   A->17   B->18   C->19   3->3
  4->4   5->5   0->0    1->1    D->20   E->21

1o DV ,  pesos 5 4 3 2 9 8 7 6 5 4 3 2
  1x5 + 2x4 + 17x3 + 18x2 + 19x9 + 3x8
    + 4x7 + 5x6 + 0x5 + 1x4 + 20x3 + 21x2
  = 5 + 8 + 51 + 36 + 171 + 24 + 28 + 30 + 0 + 4 + 60 + 42
  = 459
  459 mod 11 = 8   ->   DV1 = 11 - 8 = 3

2o DV ,  pesos 6 5 4 3 2 9 8 7 6 5 4 3 2  (inclui DV1 = 3)
  1x6 + 2x5 + 17x4 + 18x3 + 19x2 + 3x9 + 4x8
    + 5x7 + 0x6 + 1x5 + 20x4 + 21x3 + 3x2
  = 6 + 10 + 68 + 54 + 38 + 27 + 32 + 35 + 0 + 5 + 80 + 63 + 6
  = 424
  424 mod 11 = 6   ->   DV2 = 11 - 6 = 5

CNPJ completo:  12.ABC.345/01DE-35
Serpro’s canonical example: the alphanumeric CNPJ 12.ABC.345/01DE has check digits 35. The whole arithmetic, from ASCII value to remainder.

What digit validation does not prove

We return to the start, now with the math in hand. The validator answers a single question, "do the digits close?", and nothing beyond it. Two edge cases make this concrete: a valid number may correspond to no document at all, and an obviously fake number may still pass modulo 11. Open the two points below.

Valid is not existing, and existing is not in good standing

The check digit is computed from the numbers themselves, it queries no registry. So a generator can fabricate a perfectly valid CPF that was never assigned to anyone, and a real, active CPF looks exactly like a synthetic one. The only way to know it exists is the tax authority; the only way to know its registry status is an authorized lookup. "Valid" lives on your machine; "existing" and "in good standing" live on the tax authority’s server.

That is why a form that validates only the digit accepts, without blinking, a test CPF that does not exist. This is not a bug: it is the limit of what local validation can assert. If your system needs real existence, combine digit validation (cheap, instant) with an official lookup (costly, subject to a legal basis), never swap one for the other.

Why 111.111.111-11 passes modulo 11 (and is rejected anyway)

Do the math with every digit equal to 1. The sum of weights 10..2 is 54, so S = 1 × 54 = 54; 54 mod 11 = 10; since 10 is greater than 1, DV1 = 11 − 10 = 1. Repeat for the second digit (weights 11..2, sum 65): S = 65; 65 mod 11 = 10; DV2 = 1. Both check digits come out 1, exactly the sequence’s digits. It is no coincidence: any run of a single repeated digit yields a check digit equal to that same digit, because the sum of the weights reduced modulo 11 returns the digit itself. So 000.000.000-00, 222.222.222-22 and all repeats "close" the sum.

Because these numbers are mathematically valid but obviously useless, both the tax authority and any serious validator discard them with an extra rule that runs before the calculation: sequences with all identical digits are invalid by convention. This platform’s validator does exactly that, it rejects the repeat before checking the digit.

Try it here: paste 111.444.777-35 (valid), 111.111.111-11 (repeat, rejected) or any CNPJ. It runs in the browser, sending the number nowhere.Open the tool full page

Legitimate use, LGPD and third-party data

Generating synthetic CPF and CNPJ numbers for tests is a legitimate, common technical practice: filling staging forms, seeding databases, writing automated-test fixtures, documenting an API. Because these numbers belong to no one, no personal data is involved, the same spirit as using a UUID or ULID as a throwaway identifier. The problem is never generating; it is what you do with a number that happens to match a real person’s.

  • Prefer synthetic data in automated tests, documentation, demos and staging.
  • Never use a generated number to impersonate someone or bypass third-party validation.
  • For real data, use the official tax-authority source and an LGPD legal basis.
  • Remember that CNPJ lookup is public; CPF lookup is restricted, because the CPF is personal data.
  • When migrating systems for 2026, accept letters in the first 12 CNPJ positions and keep the check digits numeric.

Frequently asked questions

Is a generated CPF from a real person?
Not necessarily. The generator creates numbers that close the check-digit calculation, but it does not query the tax authority, there is no guarantee the number exists or whom it belongs to. A synthetic CPF is indistinguishable from a real one by looks alone; the difference only shows up in an official lookup.
How does the alphanumeric CNPJ check digit work?
Each of the 12 base positions is converted to its ASCII value minus 48: digits become 0–9 and letters become 17 (A) to 42 (Z). Then you apply the same modulo 11 as the numeric CNPJ, with weights 5,4,3,2,9,8,7,6,5,4,3,2 for the first digit and 6,5,4,3,2,9,8,7,6,5,4,3,2 for the second. Both check digits stay numeric. Serpro’s example: 12.ABC.345/01DE has check digits 35.
When does the alphanumeric CNPJ take effect?
Normative Instruction RFB No. 2,229 is dated 15 October 2024. The validation rule that accepts the new format goes into production in the fiscal systems on 6 July 2026, and the tax authority starts issuing alphanumeric CNPJs from 31 July 2026. Existing CNPJs remain numeric and valid, with no change.
Why are 000.000.000-00 and repeats invalid?
Because the official rule discards CPFs with all identical digits, even when the mod-11 math closes. And it does close: any run of a single repeated digit produces check digits equal to that digit. Since they are mathematically valid but useless, they are rejected by an extra rule applied before the arithmetic.
What does the ninth CPF digit mean?
It indicates the fiscal region where the CPF was issued, per the tax authority’s ten regions, for example, 8 for São Paulo and 7 for ES and RJ. It is the region of the address given at first registration, not where the person was born or lives today. It is the only origin information the number carries; it encodes neither birth date nor sex.
Can I validate CNPJ with the same method as CPF?
The logic is the same, mod 11 with weights, but the details differ: the CNPJ has 12 base positions (against the CPF’s 9), its own weights and, in the 2026 format, converts letters by ASCII value. The algorithm is analogous, not identical. Use the CPF/CNPJ validator, which detects the type by length and applies the right weights.

The CPF/CNPJ check digit is a weighted mod-11 checksum: it proves mathematical consistency, not existence or good standing. Valid is one thing; true and in good standing are others, which only the tax authority confirms. The 2026 news is the alphanumeric CNPJ, letters in the first 12 positions, numeric check digits, calculation by ASCII value minus 48, which requires adapting databases, masks and validators. Generating synthetic numbers for tests is legitimate; using a real third party’s CPF is not (LGPD).

Sources & references

  1. Receita Federal, CNPJ will have letters and numbers from July 2026
  2. Receita Federal, Alphanumeric CNPJ rollout from 31 July 2026
  3. Serpro, Alphanumeric CNPJ check-digit calculation (PDF)
  4. Serpro, Reference code for the alphanumeric CNPJ check digit (GitHub)
  5. Receita Federal, My CPF
  6. Receita Federal, 1968: creation of the CPF registry
  7. Law 13.709/2018 (LGPD), Planalto

Related articles

SecurityHashing, encryption and encoding: the differencesThree operations that scramble text and that people constantly mix up. What separates encoding, hashing and encryption is reversibility and the key, and getting it wrong is how passwords become MD5, how collisions broke SHA-1 and why HMAC exists.DevelopmentRegex from scratch: anchors, classes and quantifiersA practical regular-expressions guide for people who code: anchors, classes, greedy and lazy quantifiers, named groups, lookahead and lookbehind, Unicode with \p{…}, and the trap that took down 10% of the internet, catastrophic backtracking (ReDoS).DevelopmentUUID, ULID and IDs: when to use eachThe eight UUID versions of RFC 9562 (v1 to v8), the name-based ids (v3/v5), the sortable ULID and its monotonicity rule, the real collision probability of v4, how to read the date out of a sortable id, and alternatives like Snowflake, KSUID and NanoID, with the criterion to pick the right key.