Fake Name Generator Online

Free · no sign-up · runs in your browser

Pro Fake User Generator for Developers

Well, you are looking for clean mock user data that just works without breaking your local database setup. We built this tool so you can spin up 500 Realistic User Profiles 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
  • 500[Bulk Records] per batch
  • 44[Full Data Fields]
  • 7[Export Formats]
  • 0[Records Stored] locally safe

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

Well, front-end engineers rarely have a finished backend to point at during sprint zero. This tool bridges that gap: grab a realistic JSON response, plug it straight into your mock server, and keep your build pipeline moving without waiting on unfinished microservices.

Full Dummy API Guide →

[Direct HTTP Responses] GET & POST Mock Fixtures

Our JSON export is a ready-to-use payload. Drop it into json-server, WireMock, or Mock Service Worker (MSW), and your fetch calls resolve instantly. The JSON Schema output describes the exact structure, so you can validate contracts and generate typed TypeScript interfaces in seconds.

[Mobile App Testing] Flutter & React Native Fixtures

Mobile engineers hit backend blockers all the time. Point your Dio, Axios, or Riverpod data layer at a local fixture backed by these records. You can test pagination, shimmer states, long names, and network edge cases long before staging APIs go live.

[Stress-Testing] CRUD, Pagination & Filter Validation

Spin up 200 to 500 records at once to test list endpoints with real page and limit queries. Check if your sort logic works, test delete cascades, and verify that your web UI handles full batches without freezing up.

[Webhook Payloads] Event Fixtures for Local Handlers

This clean JSON array works as a webhook body fixture too. Wrap the profile inside your custom event shape — like user.created or member.signup — and fire it against your local handler without needing external webhooks.

[TDD Recommendation] Where This Fits In Your Test Suite

In test-driven development, the fixture has to exist before your feature code is even written. Grab a small batch, save it inside your __fixtures__ directory, and write your assertions against predictable data. Pin a seed so nothing drifts between test runs, and share the exact same dataset across unit tests, end-to-end suites, and QA demos.

Database Seeding for MySQL & PostgreSQL

Database seeding is the quickest way to give a fresh relational database a believable initial state. Forget typing out manual INSERT statements by hand; generate a full script and execute it right away.

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

[Fast Execution] Loading Your Seed File

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

[Model Validation] Synthetic Data for Machine Learning

Need a clean dataset to develop model pipelines before real data clears governance? These records provide 24 realistic columns to test feature engineering, validate training scripts, and benchmark system runtimes safely.

Seven Export Formats, One Click Away

Every batch contains the exact same 24 fields regardless of how you export it, so you can switch formats without touching your database schemas. Our database export scripts are what engineers use most: each script emits a complete DROP, CREATE and multi-row INSERT that runs cleanly on MySQL, MariaDB, or PostgreSQL without manual edits.

[Format: JSON] Full Object Tree

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

[Format: JSON Schema] Type Contracts

A draft 2020-12 schema describing each profile. Validate test responses, generate TypeScript types, or import into Swagger and Postman.

[Format: CSV] Universal Spreadsheet

One row per user with 24 columns and a UTF-8 byte-order mark so Excel renders special characters properly without broken formatting.

[Format: Excel] Native Workbook

A clean sheet your non-technical teammates can open instantly. No extra plugins, no messy import dialogues — just open it straight away.

[Format: MySQL / MariaDB] Instant DDL

A runnable script that drops the old table, rebuilds typed columns, and inserts every row in one statement with properly escaped quotes.

[Format: PostgreSQL] Safe Sequences

The same smooth workflow using SERIAL types, double-quoted identifiers, and a sequence reset so re-running scripts never causes duplicate key conflicts.

[Format: TSV] Pipeline Friendly

Tab-separated output for command line pipelines and data ingest tools. Internal tabs and newlines are cleanly flattened.

[Format: XML] Enterprise Structure

A nested <users> document with individual user nodes, ideal for older enterprise architectures and SOAP services.

[Direct Action] Quick Clipboard Copy

Skip downloads entirely and copy formatted JSON straight into your editor, unit test, or API client body in one simple tap.

Extended Identity Fields for Realistic Test Data

Our default export provides 24 practical data columns. Check Include extended identity fields and our offline generator adds 20 extra columns per record — giving you 44 total fields for complex forms that demand comprehensive profile attributes.

[Name Variants] Real-World Names

Middle initials, full formatted names, and maiden names to test legal name changes and marital status workflows without layout breaks.

[Physical Attributes] User Profiles

Height in feet-inches and centimeters, weight in pounds and kilograms, blood type, and astrological signs calculated directly from birth dates.

[Payment Testing] Luhn-Valid Cards

Visa, Mastercard, Amex, and Discover numbers that satisfy the Luhn formula so they pass client-side validation smoothly during test checkouts.

[Identifiers] Tracking & Reference

Fictional SSNs, UPS tracking codes, and Western Union transfer numbers for testing logistics and checkout confirmation forms.

[Device & Web] Technical Signatures

Realistic user-agent strings and personal website URLs, great for filling analytics dashboards and session logging tables.

[Geographic Detail] Regional Alignment

Latitude and longitude values calculated from regional centers, keeping address coordinates believable rather than scattered across the globe.

[Safety Guardrails] How Sensitive Fields Stay Protected

  • SSNs use the 900–999 range only. The US Social Security Administration has never issued numbers in this bracket, so these numbers cannot belong to real individuals.
  • Card numbers pass Luhn checks without bank accounts. They exist strictly so client-side format checks succeed in test checkouts. Never attempt real charges with them.
  • Coordinates are approximate city centroids. They align with the selected state center with slight jitter, protecting individual privacy while remaining realistic.

Keep these test datasets inside your local development environment: do not push them to public version control or use them in production systems.

Use the Data in Your Stack

You have two simple ways to integrate this data into your workflow. Download an export file directly, or fetch records straight into your codebase with zero extra dependencies.

[cURL] Direct API Call

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

[JavaScript] Node & Browser Fetch

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] Requests Script

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"])

[CLI] Load Database Seeds

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

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

[Engineering Note] Upstream API Features

Our live mode connects to the public randomuser.me endpoint with zero API keys required. Responses are cached after the initial call, keeping roundtrips fast. In return, you receive authentic photos that let you test avatar layouts and broken image fallbacks immediately. If you need higher volumes or deterministic seed control, switch to offline mode — it runs entirely within your browser without touching the network.

How to Use This Fake User Generator

Because this workflow runs entirely inside your browser, you can go from zero to a fully seeded test dataset in under a minute. Here are the core steps to get started:

  1. 1

    [Step 1] Select Your Preferred Data Source

    Pick Live API if you want realistic portrait avatars for visual components like user cards, avatar stacks, and comment feeds. Choose Offline mode when you need rapid volume, zero network calls, deterministic seed keys, or extended fields like job title, company, UUID, and MAC address.

  2. 2

    [Step 2] Choose Your Record Count

    Slide between 1 and 500 profiles, or choose an instant preset. A count of 10 is perfect for mocking a single list screen. Jump to 100 or 250 to stress-test pagination queries, search filters, and virtual scroll bars.

  3. 3

    [Step 3] Lock in a Seed for Reproducibility

    Enter any seed string — like your ticket key or sprint number — and offline mode will reproduce the exact same records every time. This simple practice prevents intermittent flaky test failures across CI/CD runs. Leave it blank if you prefer fresh randomized profiles on each generation.

  4. 4

    [Step 4] Filter by Nationality, Gender, and Age

    Country options customize street formats, postal codes, and phone prefixes, helping you test internationalization rules. Narrow by gender or age bracket to build believable test cohorts for targeted signup flows and demographic reporting.

  5. 5

    [Step 5] Generate Data and Review Results

    Hit generate and watch your profiles render as responsive cards. Switch to Table view for dense rows, sort by any column header, or use the instant search input to isolate specific records in seconds.

  6. 6

    [Step 6] Export and Drop Straight Into Your Code

    Open the Export dropdown and pick your favorite format. Grab JSON for API mocks, MySQL or PostgreSQL for instant table creation, CSV for spreadsheets, or copy JSON straight to your clipboard with one click.

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

Well, building software with an empty database is an exercise in pure 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 our 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.