Brazilian RG Generator

Continue in the tool

More pages for this tool

Synthetic RG in a privacy-first sandbox

An RG number, even an outdated or test-only one, is personal data whenever it can be linked to an identifiable person. Staging environments often replicate production with real data "for convenience", and that is exactly where an RG identifier leaks. This page explains why generating the value locally, without depending on an existing RG, is the choice that reduces that risk.

Why generating instead of copying changes the privacy risk

A direct identifier is any value that points to one specific person without needing other information alongside it, unlike a field that only becomes identifiable when cross-referenced with other data. The RG number falls into that category: on its own, it already narrows the universe of possible people down to a single identity issued by a state authority. A staging database that copies real production RGs "to have data that looks realistic" is replicating that direct identifier into an environment that is typically less protected, with looser access control, longer retention and, sometimes, unencrypted exports into a test spreadsheet.
This site's generator never starts from an existing RG: it draws an 8-digit base right in the browser and computes the check digit with the modulo-11 formula described on the rules page, without querying any list of numbers already issued. That means the value produced does not correspond, by construction, to a specific real RG, even though it remains mathematically possible that the same sequence exists in some state, since the space of 8-digit combinations is finite. The guarantee here is one of origin: the number is born from a local draw, not from a lookup or a copy.
The bigger risk is not the generator itself, it is what happens to the value afterward: if a synthetic RG ends up in a "test customers" table that gets copied into a staging dump, an error log or a spreadsheet shared through a link, it carries the same personal-data handling a real RG would get, even though it is invented, because the system that receives the data cannot tell the two apart. That is why the recommended practice is to generate the value at test time, avoid persisting it in a long-lived database, and mark within the data itself, a prefix, a metadata field, that the RG is synthetic.

Where a synthetic RG replaces a real risk

Staging sign-up form

Input: campo obrigatório de RG num formulário de onboarding
Expected output: RG sintético gerado no navegador, nunca copiado de um cliente real

Prevents a staging database dump from carrying the same direct identifier that would appear in production.

Test-case spreadsheet

Input: coluna "RG" numa planilha compartilhada com o time de QA
Expected output: valores sintéticos, reconhecíveis por não baterem com nenhuma pessoa real

If the spreadsheet leaks through a misconfigured share link, no real person's identifier is exposed alongside it.

Client-facing demo

Input: tela de exemplo mostrando o cadastro de um "usuário fictício"
Expected output: RG sintético visível na tela, sem relação com nenhum funcionário ou cliente real

A live demo that uses a coworker's real data, even as a placeholder, still exposes that person's RG to whoever is watching.

Full tool FAQ

Does RG have national validation like CPF?

No. The RG is issued by state agencies and there is no single national algorithm comparable to the CPF's. Each Public Security Secretariat uses its own format and rule, so a number valid in one state may make no sense in another.

Does this RG pass in any system?

Is the check digit really calculated?

Does the generated RG belong to someone?

Why does the tool show SSP/SP?

Can I use it in automated tests?

Is the number sent to a server?

When should I not use this generator?

Frequently asked questions

Is a made-up RG still personal data under the LGPD?

If it does not correspond to any real person, it is not personal data of anyone: the LGPD (Law 13.709/2018) protects information related to an identified or identifiable natural person, and a purely synthetic number, generated without starting from an existing record, does not meet that criterion.

Why not just use a coworker's RG as a test example?

Because that turns a real person's personal data into a fixture, spreading that identifier across commits, spreadsheets and screenshots in a way the person almost certainly never authorized; a synthetic generator removes that person from the equation entirely.

Is generating the RG in the browser safer than asking an API to generate it?

Yes, the calculation fits entirely in a modulo-11 pass over locally drawn digits, with no network dependency at all; a generation endpoint would be an unnecessary extra surface, and it would still create a server log of every value issued.

Does a staging dump with a synthetic RG still need access control?

It is still worth keeping the same basic care as any environment, access control and limited retention, but the risk of exposing a real identity disappears; the gain from the synthetic approach is removing real people from the blast radius of a possible staging leak.

Next steps

Continue in the tool

Open full tool

Synthetic RG in a privacy-first sandbox

Why generating instead of copying changes the privacy risk

A direct identifier is any value that points to one specific person without needing other information alongside it, unlike a field that only becomes identifiable when cross-referenced with other data. The RG number falls into that category: on its own, it already narrows the universe of possible people down to a single identity issued by a state authority. A staging database that copies real production RGs "to have data that looks realistic" is replicating that direct identifier into an environment that is typically less protected, with looser access control, longer retention and, sometimes, unencrypted exports into a test spreadsheet.

This site's generator never starts from an existing RG: it draws an 8-digit base right in the browser and computes the check digit with the modulo-11 formula described on the rules page, without querying any list of numbers already issued. That means the value produced does not correspond, by construction, to a specific real RG, even though it remains mathematically possible that the same sequence exists in some state, since the space of 8-digit combinations is finite. The guarantee here is one of origin: the number is born from a local draw, not from a lookup or a copy.

The bigger risk is not the generator itself, it is what happens to the value afterward: if a synthetic RG ends up in a "test customers" table that gets copied into a staging dump, an error log or a spreadsheet shared through a link, it carries the same personal-data handling a real RG would get, even though it is invented, because the system that receives the data cannot tell the two apart. That is why the recommended practice is to generate the value at test time, avoid persisting it in a long-lived database, and mark within the data itself, a prefix, a metadata field, that the RG is synthetic.

Where a synthetic RG replaces a real risk

Staging sign-up form

Input: campo obrigatório de RG num formulário de onboarding
Expected output: RG sintético gerado no navegador, nunca copiado de um cliente real

Prevents a staging database dump from carrying the same direct identifier that would appear in production.

Test-case spreadsheet

Input: coluna "RG" numa planilha compartilhada com o time de QA
Expected output: valores sintéticos, reconhecíveis por não baterem com nenhuma pessoa real

If the spreadsheet leaks through a misconfigured share link, no real person's identifier is exposed alongside it.

Client-facing demo

Input: tela de exemplo mostrando o cadastro de um "usuário fictício"
Expected output: RG sintético visível na tela, sem relação com nenhum funcionário ou cliente real

A live demo that uses a coworker's real data, even as a placeholder, still exposes that person's RG to whoever is watching.

Full tool FAQ

Does RG have national validation like CPF?

Does this RG pass in any system?

Is the check digit really calculated?

Does the generated RG belong to someone?

Why does the tool show SSP/SP?

Can I use it in automated tests?

Is the number sent to a server?

When should I not use this generator?

Frequently asked questions