NF-e Access Key
Decodes a Brazilian NF-e access key and checks its check digit.
The access key you paste never leaves your browser — decoding the fields and validating the check digit happen entirely on your device, with no network request. The only link that leaves Nexinon is the optional button to the National NF-e Portal, which you trigger manually.
What the access key is
Every Brazilian NF-e (electronic invoice) and NFC-e (consumer electronic invoice) has an access key: a 44-digit number that uniquely identifies the invoice nationwide. It's printed on the DANFE (the paper/PDF representation of the invoice), both as plain text and encoded in a barcode/QR code, and it isn't a random number — it's the concatenation of 9 fields defined by the official NF-e layout (issuer's state, year/month of issuance, issuer's CNPJ or CPF, document model, series, number, issuance form, a random numeric code, and a check digit). That means most of the key can be decoded without querying any server — it's just math.
Why there's a check digit
The check digit (the last of the 44 digits) is computed from the other 43 using modulo 11 (cyclic weights from 2 to 9, right to left) — a public algorithm defined by the NF-e's Manual de Orientação do Contribuinte (MOC), published by CONFAZ/ENCAT. It catches typos or a one-off tampered digit: changing a single digit anywhere in the key almost always makes the check digit stop matching. Same principle as the CPF/CNPJ check digit, applied to the whole key.
Why check the key of a received invoice
Anyone who receives an NF-e from a supplier can confirm two things with mathematical certainty from the access key alone: that the key wasn't mistyped/miscopied (the check digit) and who actually issued it (the CNPJ/CPF embedded in it) — useful both to double-check a supplier's invoice and to be suspicious of a questionable one. What this tool can't confirm is whether SEFAZ actually authorized that specific invoice (it may have been canceled, denied, or never really existed, even with a mathematically well-formed key) — use the National Portal link shown with the result for that.
Issuer's CNPJ or CPF
The key's 14-position document field almost always carries the issuing company's CNPJ — but, since a layout change (NT 2018.001), it can also carry the CPF of an individual issuer, most commonly a rural/primary producer issuing an invoice without a CNPJ. In that case the CPF (11 digits) appears preceded by three zeros, filling the field's 14 positions. This tool detects both cases automatically and shows the right document, already validated by its own CPF/CNPJ check digit.
Fields whose meaning has already changed over time
Two fields in the key carry a short code whose meaning has changed as the NF-e project evolved, without the key's format itself changing: issuance-form code 3 used to identify SCAN (a national contingency system, now decommissioned) and today identifies the NFF Special Regime (Nota Fiscal Fácil, aimed at rural producers); code 4 appears in the official technical schema itself as "DPEC contingency", the historical name for the same mechanism now called EPEC (Evento Prévio de Emissão em Contingência). This tool always decodes by the current meaning — an older key with these codes still decodes correctly, just under today's name, not the one the code had in the past.
Frequently asked questions
No. A match only confirms the key is mathematically well-formed — that is, nobody mistyped/miscopied it, or altered a single digit after it was generated. It does NOT guarantee SEFAZ authorized that invoice, or that it wasn't later canceled or denied: a bad actor can generate a fully valid, well-formed key with their own real data. To confirm the real status, use the National Portal link shown with the result.
Because the issuer is an individual, not a company — the most common case is a rural/primary producer, who in some states can issue an NF-e with an e-CPF certificate instead of e-CNPJ. In those cases the access key carries the issuer's CPF, preceded by zeros to fill the 14 positions of the field that normally holds a CNPJ.
The official NF-e layout only defines two possible values for the document model field: 55 (NF-e) and 65 (NFC-e). If the pasted key has a different value there, it doesn't correspond to any valid Brazilian electronic fiscal document — it could be a made-up or corrupted key, or a different document type outside this tool's scope that shares the same key format (e.g. CT-e, MDF-e, which use different model codes).
Because that requires querying the responsible SEFAZ system in real time — it isn't information that exists inside the key itself. A National NF-e Portal does offer that lookup (link shown with the result), but it requires solving a captcha on every query, with no confirmed public API to automate it. So this tool never tries to read that status on its own — it's never worth trusting without that confirmation.
No. No key pasted here ever leaves your browser — there's no network request, no server-side storage. All decoding and check-digit computation happen locally, on your own device. The only thing that leaves Nexinon is the external National Portal button, and only when you click it.
On the DANFE (the paper or PDF document that represents the NF-e), the key is printed as text, usually in groups of 4 digits, right below or next to the barcode/QR code — both encode the exact same key, just in different formats (optical scanning vs. manual typing).
Because it doesn't mean anything by design — it's a random value the issuer generates when assembling the key, meant only to make it harder for someone to guess another invoice's key (the MOC is explicit about this: every other field can be deduced by anyone, so the numeric code needs to be genuinely random for the key not to become predictable). That's why it's only shown raw, never with an explanation of "what it means".
No — Nexinon deliberately keeps generation tools separate from verification/anti-fraud tools. This tool only decodes and validates an access key that already exists, it never creates a new one.
Because that's all the access key carries — the `AAMM` field has 4 digits (2-digit year + month), with no room for the day. The full date (day included) lives in the invoice's XML file, not in the access key; decoding the full XML is a much larger scope, outside this tool.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.