Alphanumeric CNPJ Validator

How does the alphanumeric CNPJ work?

With IN RFB 2.119/2022 and the SERPRO updates came the new CNPJ format, which now lets letters (A-Z) sit in the first 12 characters. The last two stay numeric and play the role of check digits.

For the DVs, the modulo 11 algorithm with cyclic weights stays in place (5,4,3,2,9,8,7,6,5,4,3,2 for the first DV; 6,5,4,3,2,9,8,7,6,5,4,3,2 for the second). What changes is each character's numeric value, taken from charCode - 48, so that A=17, B=18, …, Z=42.

It runs entirely in the browser and takes input with or without the mask.

The alphanumeric CNPJ: what changes on July 1, 2026

The Brazilian federal tax authority (Receita Federal) is exhausting the 14-digit numeric range of the CNPJ. To extend the lifetime of the identifier without forcing a breaking renumbering, Normative Instruction RFB 2.229/2024 introduces the CNPJ alfanumérico: the 12 base characters become alphanumeric (letters A–Z plus digits 0–9), while the 2 check digits remain numeric. The rollout starts on July 1, 2026 and only affects new issuances; legacy purely-numeric CNPJs remain valid forever and require no migration.

For developers, the news is that every layer of the Brazilian fiscal stack that treats CNPJ as NUMERIC(14) will break: database columns, regex patterns, XML schemas, input masks, JSON schemas and even some printed forms. Validating an alphanumeric CNPJ correctly is the entry point of any migration effort, and is exactly what this tool does in your browser.

Format: 12 alphanumeric + 2 numeric check digits

The official layout published by the Receita Federal is:

• Positions 1–8: alphanumeric root of the establishment ([A-Z0-9]{8}).
• Positions 9–12: alphanumeric branch order ([A-Z0-9]{4}), with 0001 being the default for the headquarters under the old scheme.
• Positions 13–14: two numeric check digits ([0-9]{2}), computed modulo 11 over the first 12 positions.

A canonical pre-filter regex is:

^[A-Z0-9]{12}\d{2}$

The convention is uppercase only. Lowercase letters must be normalized to uppercase before validation; mixed case must be rejected at the input layer. This tool already uppercases automatically.

The check-digit algorithm step by step

The check-digit math is identical to the legacy CNPJ — only the input representation changes. Letters are converted to numbers using their ASCII value minus 48, which gives A=17, B=18, C=19, ..., Z=42. Digits 0–9 keep their numeric value. After conversion, apply modulo 11 with the standard CNPJ weights:

weights_DV1 = [5,4,3,2,9,8,7,6,5,4,3,2]
weights_DV2 = [6,5,4,3,2,9,8,7,6,5,4,3,2]

for each char in base12:
  value = ord(char) - 48   # works for 0-9 and A-Z

DV1 = mod11_sum(values, weights_DV1)
DV2 = mod11_sum(values + [DV1], weights_DV2)

The rule for the remainder is the same as the numeric CNPJ: if resto < 2 then DV = 0, otherwise DV = 11 - resto. The output is always a digit 0–9; the check digits are never letters.

Migration impact for Brazilian developers

The migration touches a long list of components:

• Database schema: NUMERIC(14) or BIGINT columns must become VARCHAR(14) or CHAR(14). PostgreSQL users should consider CITEXT for case-insensitive lookups.
• Indexes: numeric indexes on CNPJ must be rebuilt as text indexes. Partial indexes on legacy data remain valid.
• Regex updates: any ^\d{14}$ pattern must become ^[A-Z0-9]{12}\d{2}$. Hardcoded numeric regex is the single most common antipattern.
• DOM input masks: libraries like jquery.mask, imask and react-input-mask default to digits only; switch to a custom pattern that accepts A-Z0-9.
• JSON Schema: "type":"string","pattern":"^[A-Z0-9]{12}\\d{2}$" instead of "type":"integer".
• NF-e XML layout: SEFAZ published Nota Técnica 2024.002 updating the XSD to accept alphanumeric CNPJ in the emit and dest tags.
• Libraries: cpf-cnpj-validator (npm) ships alphanumeric support from v3.0; older versions break silently.

Backward compatibility and the transition window

Existing CNPJs (purely numeric) do not change. After July 1, 2026 every system must accept both formats simultaneously. Validators must therefore route the input through a single function that handles both cases — typically by always converting characters to numbers via ord(char) - 48, which gives the correct integer for digits and the expected mapping for letters.

Receita Federal will publish a SEFAZ sandbox (homologation environment) supporting alphanumeric CNPJ ahead of the production cutover, so ERPs can rehearse XML emission, signature and protocol consultation with the new layout before the legal deadline.

Common pitfalls and antipatterns

The recurring traps observed in early migrations:

• Hardcoding ^\d{14}$ in a brand-new system in 2025 — guarantees breakage in July 2026.
• Storing the CNPJ as BIGINT on a fresh schema; even if the current value fits, the column type cannot accept letters.
• Trusting the check digits to detect a typo where letter O was typed instead of digit 0 — modulo 11 catches transpositions but not all substitutions, especially with the limited domain of confusable chars.
• Forgetting to uppercase user input — "abc" and "ABC" are not the same CNPJ.
• Forgetting that the check digits stay numeric — accepting alphanumeric DV is a bug.

FAQ

When does the alphanumeric CNPJ become official?

July 1, 2026, per Normative Instruction RFB 2.229/2024. From that date onward, new CNPJ registrations may receive an alphanumeric value; existing CNPJs remain valid unchanged.

Is this a breaking change for my numeric validators?

Yes. Any regex or schema that enforces 14 numeric digits will reject valid alphanumeric CNPJs. Update validators, database columns, masks and XML schemas before the cutover.

Do legacy CNPJs need to be migrated?

No. Existing CNPJs stay numeric forever. Only new issuances after July 2026 may be alphanumeric. Your system must accept both formats from the same validator function.

Are the check digits also letters?

No. The last 2 positions are always numeric (0–9). Only the first 12 positions can be alphanumeric. A valid alphanumeric CNPJ matches ^[A-Z0-9]{12}\d{2}$.

Are letters case-sensitive?

The convention is uppercase A–Z. Validators should uppercase the input before processing. This tool does it automatically on the input field.