Brazilian voter ID for test fixtures
A registration form that validates a voter ID usually checks the length, a state code within the 01 to 28 range, and two chained check digits. This generator returns the correct 12 digits, with the state code you pick, for a reproducible fixture.
No spaces or punctuation: use it directly in the request body for a registration API that expects the raw 12-digit string.
The mask separates the sequential block, state code and check digits into three groups of 4; use this value to test the masked input in the browser.
Pinning the state code to 20 is useful for testing a screen that derives the voter state from the number itself, without depending on whatever state the generator would draw by default.
Yes. The number includes two check digits calculated from the sequence and state code.
If the form only validates format (length, check digits), one code is enough; if it also derives the voter state from the number to display on screen, test at least one code from each end of the 01-28 range to make sure the parser neither truncates nor overflows the interval.
It does: you cannot compute both check digits in parallel, the second only exists once the first has been calculated, so a hand-written fixture (without running the generator) needs to follow that order or it will produce a number that fails validation.
Yes, and it is good practice: keeping the sequential block fixed and only swapping the state code makes both check digits change predictably, which helps a test isolate whether a bug lives in the state logic or the sequential logic.
Use the unspaced version (123456780191) directly in the payload, and reserve the spaced version for display or mask-parser tests only; mixing the two in the same assertion is the most common cause of this kind of failure.
Generation happens locally in the browser. Analytics receives only action, status, type and format, never the generated voter ID.