Random people and companies for testing: name, address, phone and email from one country, plus valid Russian INN, SNILS, OGRN and bank account. A seed for repeatable sets, JSON / CSV / SQL export.
Test data only — not PII. Generated in your browser.
drawn from the name, it is not a photo of a person
Seed
Empty — a new set every time. The seed used is shown above the result.
02
Personas
click a value to copy it
Format
Personas are assembled in your browser — press Generate if the set has not appeared.
03
About the persona generator
Test personal data means plausible but non-existent names, phone numbers, cities and Russian tax and pension IDs (INN and SNILS). It is generated so that real people's data never ends up in development or demos: under Russian law 152-FZ that would be processing personal data, with every obligation it carries. Random digits will not do — forms validate check sums. Here INN and SNILS pass the tax service and pension fund algorithms, the email and login are built from the same name, and up to a hundred personas at a time export to JSON, CSV or SQL.
Test data only
Not PII
random names · random INN · random SNILS
Everything is generated at random and does not match real people. INN and SNILS pass their checksums, but they are not real documents. Use them only for testing, development, learning and mockups.
Transliteration & validation
GOST 7.79
email from the name · SNILS with checksum
Email and login transliterate the Russian name with GOST 7.79-2000 system B: Хабенский becomes xabenskij, Цыганов becomes cyganov. SNILS has a valid checksum, and the individual INN (12 digits) follows the tax service algorithm with two check digits.
Data that matches the country
Locale
München · Bayern · 803xx · +49 89
The name, phone, city with its region, address style, postcode and email domain all come from one country set. That is why a persona looks real: no “Munich, Texas” and no Russian number for John Smith.
Seed and repeatability
QA
seed=abc → the same set
One seed and the same settings give the same set of personas until the end of the calendar year; only the age changes on a birthday. Test fixtures stay put between runs, and email, login, INN and cards stay unique, so inserts into a table with a unique index do not fail.
Companies with details
Companies
INN-10 · KPP · OGRN · account by BIC
Company mode for Russia: LLC, JSC and sole traders with INN, KPP, OGRN or OGRNIP, a bank account with a valid BIC check key, OKVED and OKPO. INN, KPP and OGRN pass the neighbouring checker; the bank and BIC are made up.
For demos and screenshots you can use people from IT history (Famous) or world icons — space, music, literature, science, film, politics (Famous World) — no repeats, respecting the chosen gender, with a note on who each person is. Birth and death dates and the company are real; phone, email, address and card stay synthetic, and the avatar is a pattern drawn from the name, not a photo.
04
Frequently asked questions
Pick a country and press generate: you get a full set of name, date of birth, address, phone, email and documents, all from that one country. Personas come in batches and export as JSON, CSV or a ready SQL insert. Set a seed and the same settings give the same set again, so test fixtures stay put between runs.
No. Values are assembled at random from lists of common names, surnames, cities and occupations; no database of real individuals is involved. A match with a living person is possible the way namesakes match. Russian INN and SNILS pass their checksums but were never issued. Checksummed IDs exist only for Russia — no national numbers are generated for other countries.
It depends on the country. US and UK numbers come from ranges set aside for fiction — 555-0100…0199 and 07700 900xxx — so nobody will answer. For Russia, Germany, Kazakhstan and Belarus the operator or area code is genuine and the rest is random, so the number may belong to someone. Use it to test input masks, never to call or text.
You should not. It exists for testing and demonstration — filling a form during development, showing an interface in a screenshot, seeding a training database. Registering with invented details breaks the terms of most services and leaves you locked out when account recovery asks for them.
So that development databases never hold real personal data. Production data in test environments is a classic source of leaks: those databases are protected less carefully and end up on laptops and in shared folders far more often. Synthetic records remove that risk completely.
No. Everything is assembled in your browser from word lists shipped inside the page, with no network request at all. Personas are stored nowhere; the only way back to a set is its seed — the same seed and settings give the same set. The page address keeps the seed and settings, never the personas. Only the tool name is sent, for a popularity counter.