Fake Name Generator Online

Free · no sign-up · runs in your browser

Pro Fake User Generator for Developers

Produce up to 500 realistic dummy user records in a single click, then export the whole batch as JSON, CSV, Excel, SQL or XML. Built for API mocking, database seeding and front-end testing — filter by gender, age and country, pin a seed for reproducible fixtures, and drop the result straight into your test environment.

CG Built and tested by Chandra G. (Lead Full-Stack Engineer & QA Architect) · Testing Methodology
  • 500records per batch
  • 24exportable fields
  • 7export formats
  • 0records stored

Fake user generator tool

10 users selected

Data source

Drives names, street format and phone layout.

Offline mode. Same seed = same data, every time.

Filters the visible list and every export.

API mode calls randomuser.me. Switch to offline mode for unlimited volume and no network calls.

API Mocking & Dummy Payloads for Frontend Testing

A front-end team rarely has a finished backend to point at. This tool fills that gap: generate a realistic JSON response, load it into your mock server, and develop against a stable JSON response shape while the real RESTful architecture is still being built.

Full Dummy API Guide →

For HTTP GET and POST mock responses

The JSON export is a ready-made payload. Serve it from json-server, Mock Service Worker, WireMock, MSW, or a static file on localhost, and your fetch() calls resolve immediately. The JSON Schema export describes the same shape, so you can validate requests and responses, generate typed TypeScript interfaces, or wire it into Swagger and Postman.

For Flutter, React Native and mobile apps

Mobile developers can hit the same gap in a different place. Point your Dio, axios or Riverpod repository layer at a local mock endpoint backed by these records and you get pagination, empty states, long-name overflow and error handling working before the API contract is finalised.

For CRUD and pagination testing

Generate 200 to 500 records in one go to exercise GET list endpoints with page and limit parameters, verify your sort query, check that a POST-then-DELETE cycle frees the right slot, and confirm your UI survives a full result set instead of three rows.

For webhook payload fixtures

The flat JSON array works as a webhook body fixture too. Rename the object to match your event — customer.created, invoice.paid — and replay it against your handler in a local test environment without touching the real provider.

Where this tool fits in a TDD workflow

In test-driven development the fixture usually has to exist before the feature does. Export a small batch as JSON, drop it in your __fixtures__ folder, and your unit tests assert against a known payload. Pin a seed so the fixture never drifts, then let the integration tests and your local localhost environment use a larger batch. The same data serves unit testing, integration testing and QA automation without being rewritten three times.

Database Seeding for MySQL & PostgreSQL

Database seeding is the fastest way to give a relational database a believable starting state. Instead of writing an INSERT statement by hand, generate a complete script and run it.

Full DB Seeding Guide →
Export formats compared
Export Best for Notes
MySQL / MariaDB Seeding a local or staging relational database Includes DROP, typed CREATE and one multi-row INSERT
PostgreSQL Same workflow on Postgres, Supabase or RDS Uses SERIAL, double-quoted identifiers and a sequence reset
CSV COPY imports, migrations, bulk loads One row and column per field, UTF-8 BOM for Excel
JSON NoSQL stores, API payloads, config files Full fidelity, pretty-printed for diffing in git
Excel (.xls) Sharing a dataset with non-technical teammates Opens natively in Excel and Google Sheets

Loading it

MySQL and MariaDB: mysql -u root -p mydb < fake-users.sql. PostgreSQL: psql -d mydb -f fake-users.postgres.sql. Both scripts are self-contained, so re-running them simply resets your test data.

Synthetic data for machine learning

Need a dataset to develop a model pipeline against before real data clears governance review? These records give you 24 realistic columns to prototype feature engineering, validate a training script and benchmark your pipeline’s runtime.

Seven export formats, one click away

Every batch contains the same 24 fields regardless of how you export it, so you can move between formats without changing your schema. The database options are what developers reach for most: both emit a complete DROP, CREATE and multi-row INSERT script that runs on MySQL, MariaDB or PostgreSQL with no editing.

JSON

An array of nested objects with pretty-printed indentation. The natural choice for API mocks, seed scripts, fixtures and anything you pipe into fetch.

JSON Schema

A draft 2020-12 schema describing one record. Validate responses, generate TypeScript types, or import into Swagger and Postman as a contract.

CSV

One row per user, 24 columns, with a UTF-8 byte-order mark so Excel opens accented names correctly. Quotes and commas inside values are escaped properly.

Excel (.xls)

A spreadsheet your non-technical teammates can actually open. No plugin, no import dialog — double-click and the data is in Excel or Google Sheets.

MySQL / MariaDB

A runnable script: drop the table, recreate it with typed columns, then insert every row in a single statement. Single quotes in text are doubled to avoid SQL errors.

PostgreSQL

The same workflow with SERIAL, double-quoted identifiers and an explicit sequence drop, so re-running the script never collides on the primary key.

TSV

Tab-separated output for tools that prefer it, including some database importers and Linux pipelines. Tabs and newlines inside values are flattened.

XML

A nested <users> document with one <user> per profile, still useful for SOAP services and older enterprise integrations.

Copy to clipboard

Skip the download entirely and paste JSON straight into your editor, test file or HTTP client body field.

Extended identity fields for realistic test data

The default export gives you 24 practical columns. Tick Include extended identity fields and offline mode generates 20 more per record — 44 in total — for the cases where a form needs more than a name and an email address.

Name variants

Middle initial, full name including the middle initial, and a maiden name for testing surname-change and marital-status flows.

Physical attributes

Height in feet-and-inches plus centimetres, weight in pounds and kilograms, blood type, and a zodiac sign derived from the date of birth.

Payment test data

Visa, Mastercard, Amex and Discover numbers that satisfy the Luhn checksum, so they pass the client-side format validation most payment forms perform.

Identifiers

An SSN, UPS tracking number, Western Union reference and MoneyGram reference for testing shipping and remittance integrations.

Device and web data

A user-agent string and a personal website URL, useful for populating analytics tables, session records and browser-detection logic.

Geographic detail

Latitude and longitude derived from the record’s state, so coordinates are internally consistent rather than randomly scattered across the globe.

How the sensitive fields are made safe

  • SSNs use the 900–999 area range only. The US Social Security Administration has never issued a number in that range, so a generated SSN cannot collide with a real person’s.
  • Card numbers pass the Luhn checksum but map to no account. They exist so a payment form’s format validation succeeds during testing. Never attempt a real transaction with one.
  • Coordinates are city-level. They are derived from the state centroid with a small jitter, which keeps the data internally consistent without implying a precise location.

Treat any batch containing these fields as test-only: keep it out of version control, out of production databases, and out of any shared demo environment.

Use the data in your stack

Two ways to get this data into your project. Download a file and import it, or call the endpoint directly from your own code with no dependency on this website.

Direct API call

curl "https://randomuser.me/api/?results=25&nat=gb"

JavaScript / Node

const res  = await fetch(
  'https://randomuser.me/api/?results=25&nat=us'
);
const data = await res.json();

console.log(data.results[0].name);  // { first, last }
console.log(data.results[0].email); // user@example.com (fictional)

Python

import requests

r = requests.get("https://randomuser.me/api/",
                 params={"results": 25, "nat": "de"})
users = r.json()["results"]

for u in users[:3]:
    print(u["name"]["first"], u["email"])

Load the seeding script

# MySQL / MariaDB
mysql -u root -p demo_db < fake-users.sql

# PostgreSQL
psql -d demo_db -f fake-users.postgres.sql

Good to know about the upstream API

The live mode is powered by the free public randomuser.me endpoint. It needs no key and no account, and the data is cached after the first load, which makes repeat calls fast. In exchange you get realistic photographic avatars, which is exactly what you want when you are testing image loading, cropping and fallback states. If you need volume above a few hundred records, UUIDs, IP addresses or a reproducible seed, switch to offline mode — it never touches the network at all.

How to use this fake user generator

The whole workflow runs in your browser, so you can go from nothing to a usable dataset of test users in well under a minute. Here is the complete process, with the decisions that actually matter.

  1. 1

    Choose your data source

    Live API calls randomuser.me and returns profiles with real human photographs. Use it when you are building anything visual — avatar stacks, profile cards, comment threads, table rows with images — because layout bugs around image aspect ratios and loading states only show up with actual images. Offline mode assembles records from dictionaries compiled into this page. It needs no network, has no rate limit, and adds developer-oriented fields such as job title, company, UUID, IPv4 address, MAC address and a strong random password.

  2. 2

    Set the record count

    Use the slider for any value from 1 to 500, or pick a preset from the dropdown. Ten records is usually enough to build a realistic list page. Jump to 100 or 250 when you want to stress-test pagination, sorting, search and virtual scrolling, and use 500 when you are checking how your interface behaves with a genuinely large payload.

  3. 3

    Pin a seed if you need repeatability

    Type anything into the seed field — a sprint name, a ticket number, your own name — and offline mode will produce the exact same dataset every time you enter it. This is the difference between a test that is reproducible and one that mysteriously fails on CI. Leave it blank when you want a fresh batch on every click.

  4. 4

    Apply filters to shape the dataset

    Country or region changes the name pool, the street style, the postcode format and the phone number layout, so testing against the market you actually ship to catches formatting bugs a US-only dataset would hide. Gender and age range narrow the cohort further, which is how you generate a believable user base for a survey, an onboarding funnel or a demographics dashboard instead of fifty twenty-something Americans.

  5. 5

    Click Generate Data and review the results

    A spinner appears while the profiles are created, and the batch renders as a responsive card grid showing each person’s photo, name, username, email, address and phone number. Switch to Table view for a denser, spreadsheet-like layout, sort by any column, and use the search box to isolate a subset. The search box is the fastest way to find one specific record in a batch of 500.

  6. 6

    Export and drop it into your project

    Open the Export menu and pick your format. JSON for mock API payloads and seed scripts, JSON Schema to generate types or validate responses, MySQL or PostgreSQL to load a real database you can query immediately, CSV or Excel for spreadsheets and QA matrices, TSV for pipelines, XML for legacy services, or copy to clipboard if you are pasting straight into your editor. Whatever you export respects the current search filter, so you can generate 500 records and still ship a clean 12-row sample file.

Engineering Knowledge Base

In-Depth Developer Guides & Tutorials

Deep-dive technical guides on synthetic data compliance, frontend API mocking, and relational database seeding.

Why Modern Engineering Teams Rely on Dummy Data

Building software with an empty database is an exercise in frustration. You spend days polishing a user profile screen, writing a search endpoint, or preparing an executive demo, only to realize you have no data to render. You end up manually inserting three rows in phpMyAdmin or pgAdmin: John Doe, Jane Doe, and a test user with a broken avatar. The UI looks clean on your localhost, but it hides every real-world bug. You cannot verify how an avatar card behaves with a 45-character hyphenated surname, whether translated street addresses break your flexbox grid, or how pagination queries perform when there are more than 10 rows.

The traditional shortcuts developers take are notoriously hazardous. Pulling a sanitized copy of a production database into a staging environment or local Docker container is a compliance nightmare under modern privacy regulations. Hand-rolling a throwaway script with Faker libraries takes hours of setup before you write a single line of feature code. Waiting on backend engineers to deliver working seed endpoints introduces scheduling dependencies that kill sprint velocity.

That is where a dedicated dummy data generator and fake user generator becomes an essential developer tool. It instantly produces realistic, messy datasets: varying name lengths, localized international phone numbers, diverse age distributions, and synthetic avatars that expose layout breaks on mobile screens. Because the records are completely fictitious, you can run load tests, wipe databases, and share demo environments without risking a data breach.

The biggest return on investment is test quality. A batch of 500 records generated by our test data generator acts as an authentic test corpus. It catches off-by-one pagination bugs, unexpected sorting collisions on identical timestamps, and rigid string-length validation assumptions right at your desk. Fixing these defects during local development takes minutes; diagnosing them after an incident report from production takes days.

Senior engineers prioritize deterministic seed generators for a reason. When randomized data changes on every test run, failing assertions turn into intermittent "flaky tests" that waste CI pipeline minutes. Pinning a seed (e.g. seed: "sprint-24") guarantees that our mock data generator outputs the exact same 50 or 500 rows every single run, turning elusive edge cases into reproducible bugs you can inspect and fix.

Understanding the distinction between mock data, fake data, and synthetic data keeps test suites maintainable. Mock data gives you predictable fixtures for unit tests and contract testing; fake data provides varied attributes for form validation and UI stress-testing; and synthetic data statistically mirrors real user distributions for database indexing and machine learning.

Our goal is simple: eliminate test data friction. No accounts, no subscriptions, no leaked API keys, and no heavy packages to install. Generate your batch, export to JSON, CSV, or runnable MySQL and PostgreSQL seed scripts, and drop the data straight into your project.

Frequently asked questions

Are the generated users real people?

No. Every profile is fictional. The API mode draws on randomuser.me, which assembles records from dictionaries of invented first names, surnames, streets, cities and email domains, and the offline mode uses word lists compiled inside this page. No real individual’s personal data is collected, stored, displayed or downloaded, and nothing is linked to any live account or inbox.

What is the difference between the API mode and the offline generator?

API mode calls randomuser.me and returns profiles with real human photographs, which is ideal for UI work where avatar layout and image loading behaviour matter. The offline generator runs entirely inside your browser, so it needs no network connection, produces no API traffic, and adds developer-oriented fields such as job title, company, company size, UUID, IPv4 address, MAC address and a strong random password. It also supports a deterministic seed, so the same seed always returns the same dataset for repeatable tests.

Can I use the generated data in a commercial project?

Yes. The data is generated for general-purpose use in development, staging and demo environments, unit and integration tests, database seed scripts, API fixtures, design mockups and prototypes. Because the profiles are synthetic rather than real, they are safe to include in client demos and shared test databases. You should still avoid presenting the data as genuine customer records, and never use generated passwords, identity numbers or payment details for anything outside testing.

How do I export the fake users to JSON, CSV, Excel, SQL or XML?

After you generate a batch, open the Export menu beneath the results. JSON produces the full nested object array and is best for API fixtures and mock endpoints. JSON Schema describes that shape as a draft 2020-12 schema, which you can validate responses against or convert into TypeScript interfaces. CSV gives one row per user with 24 columns, ideal for spreadsheets and QA matrices, and Excel produces a file that opens natively with no import dialog. For database seeding, MySQL / MariaDB and PostgreSQL each emit a complete DROP, typed CREATE and multi-row INSERT script that runs without editing. TSV is the tab-separated variant and XML suits SOAP and legacy integrations.

Can I use this as a dummy REST API for front-end testing?

Yes, and it is one of the main reasons this tool exists. Export a batch as JSON, serve it from json-server, Mock Service Worker, WireMock, MSW or a plain file on localhost, and your fetch() calls resolve immediately while the real backend is still being built. The same records work as HTTP GET and POST payloads for React, Vue, Flutter and React Native clients, and as webhook body fixtures you can replay against a handler in your test environment. Pin a seed so the payload never changes between runs.

What are the extended identity fields, and are they safe?

Ticking Include extended identity fields in offline mode adds 20 columns per record: middle initial and maiden name, height, weight, blood type, zodiac sign derived from the date of birth, occupation, vehicle, personal website, user-agent string, UPS, Western Union and MoneyGram references, city-level coordinates, plus a Luhn-valid test card number and an SSN. The sensitive fields are built to be unusable by accident: SSNs are generated only in the 900–999 area range that the Social Security Administration has never issued, and card numbers satisfy the Luhn checksum without mapping to any account, which is exactly what a payment form needs to accept a test value. Even so, treat these batches as test-only and keep them out of version control and production.

Is my data stored or sent anywhere?

No. Generation, filtering, sorting and export all happen inside your browser using JavaScript. The optional live API call goes directly from your browser to randomuser.me and this site never sees or proxies it. There is no account, no database, no analytics profile and no server-side copy of your dataset. Closing the tab discards everything, which makes the tool safe for confidential schema designs and unreleased feature work.