Faker (faker-js/faker): fake data for tests, seeded and localized

What Faker generates and who reaches for it

Faker produces fake but realistic data. The README lists the modules it covers: person (names, genders, bios, job titles), location (addresses, zip codes, street names, states, countries), date (past, present, future, recent, soon), finance (account details, transactions, crypto addresses), commerce (prices, product names, adjectives, descriptions), hacker phrases, and plain numbers and strings. The audience is developers who need fixture data: test authors writing unit or end-to-end tests, frontend engineers filling a table or a form with something more readable than "test test", and anyone prototyping a UI before a real backend exists.

The README carries a warning worth repeating because it changes how you treat the output. Faker aims at realistic data rather than obviously fake data, so generated names, addresses, emails and phone numbers may be coincidentally valid. The README asks that you not send messages or calls to them from your test setup. That is the difference between Faker and a counter that emits [email protected]: the output looks real enough to be mistaken for real.

Modules, templates and the mustache helper

The API is organized as method namespaces hanging off a faker instance, so a record is assembled by calling faker.string.uuid(), faker.internet.username(), faker.date.birthdate() and so on. There is no schema, no model definition and no ORM hook. The library returns primitives and you decide the shape of the object.

One generator does more than return a primitive. faker.helpers.fake takes a mustache-style template string and resolves the placeholders against the same API, which is useful when you want a human-readable sentence rather than a field-by-field construction. The README's example is a greeting built from person.prefix and person.lastName. Bulk generation is handled by faker.helpers.multiple, which takes a factory function and a count and returns an array, so you do not write the loop yourself.

Because the whole surface is a set of pure-ish functions over an internal random source, the architecture is simple: no network calls, no database, no configuration file. The state that matters is the random seed and the locale data bundled with the build.

Installing @faker-js/faker and generating a first record

The README gives a single install command, and it is a dev dependency rather than a runtime one. Run it in the project where your tests live:

npm install --save-dev @faker-js/faker

Import the faker instance and call the namespaces you need. The README shows both module systems; the ESM form is the one to copy into a modern project:

// ESM
import { faker } from '@faker-js/faker';

export function createRandomUser() {
  return {
    userId: faker.string.uuid(),
    username: faker.internet.username(),
    email: faker.internet.email(),
    avatar: faker.image.avatar(),
    password: faker.internet.password(),
    birthdate: faker.date.birthdate(),
    registeredAt: faker.date.past(),
  };
}

Calling createRandomUser() returns an object with a UUID string, a username, an email, an avatar URL, a password string and two dates. Nothing is written to disk and no server is contacted. For an array of records, the README uses faker.helpers.multiple with a count option:

export const users = faker.helpers.multiple(createRandomUser, {
  count: 5,
});

If you want the same five users on every run, seed the generator first. The README documents that setting the seed again resets the sequence, so the same seed yields the same first value:

faker.seed(123);

const firstRandom = faker.number.int();

faker.seed(123);

const secondRandom = faker.number.int();

The README notes there are additional considerations when faker.date methods are involved and points to the Reproducible Results page on fakerjs.dev. That is the first place to look if seeded output still drifts between runs.

Locales, fallback and building your own instance

The main faker instance is English. Other locales arrive as separate named exports, so German data comes from fakerDE, and the README shows aliasing it to faker on import. The README claims over 70 locales.

The important constraint is coverage. Not every locale provides data for every module, and the pre-made instances fall back to English when a locale is missing something, on the reasoning that English is the most complete and most commonly used. That fallback is convenient and also easy to miss: a German address can end up with an English-language fragment in a field nobody checked. If silent fallback is unacceptable, the README shows constructing a Faker instance directly with an ordered locale array, for example de_CH followed by de, so you control the chain. Building your own instance is the escape hatch, not the default.

Where Faker is the wrong tool

Faker is a generator, not a data store. It has no notion of foreign keys or referential integrity, so two calls that should describe the same person produce two unrelated people unless you keep the object yourself. There is no built-in guarantee that a generated email matches the generated username, or that a birthdate precedes a registration date. If your tests depend on cross-record consistency, you are writing that logic on top of the library.

Reproducibility is conditional. Seeding makes a sequence repeat, but the README itself flags extra considerations for date methods, and any change to the library version can change what a given seed produces. A snapshot test that pins seeded output is therefore coupled to the Faker version, which matters when you upgrade.

The data is also not anonymized data. It is invented data. If the goal is to take a production database and strip personal information from it, Faker does not read your database and does not preserve the statistical shape of it; it produces new values. That is a different job.

Finally, the realistic output is a mild liability. The README warns that generated contact details may be coincidentally valid, so generated emails and phone numbers should not be pointed at real delivery systems.

Alternatives and the difference in approach

The most direct comparison is with hand-written fixture factories: plain functions or object literals that return fixed records. Those are deterministic by construction and cost nothing to reason about, but they do not vary, and a fixed email or ID will eventually collide with a unique constraint or hide a bug that only appears with varied input. Faker trades that determinism for volume and variety, and gives you seeding when you want determinism back.

The other family is schema-driven mock servers, which read an API specification and serve generated responses over HTTP at a URL. Faker does not start a server and does not read a specification; it is a library you call inside your own code. If your tests need an HTTP endpoint that mimics a backend, a mock server is the closer fit, and Faker is the piece you would use to fill its payloads.

For Python projects there is a separate Faker package with its own API and its own install path, and the two are not interchangeable: the JavaScript library documented here is installed from npm as @faker-js/faker, while the Python one is a different distribution with different method names.

Maintenance, licence and the version question

The repository is not archived and the last push was on 2026-09-21, with v10.6.0 released on 2026-08-14. The default branch is next, and the README states plainly that its own documentation describes that next branch, directing readers to fakerjs.dev for the stable release. The version table in the README lists v11 (next) at next.fakerjs.dev, v10 (stable) at fakerjs.dev, and v9 at v9.fakerjs.dev. Anyone reading API docs should check which of those three matches the version in their lockfile, because the branch you land on by default is not the stable one.

Upgrade cost is real but bounded. Releases are versioned and the changelog is in the repository, so the diff between v10.4.0, v10.5.0 and v10.6.0 is inspectable. The larger risk is behavioural: seeded output can shift across versions, so any test that asserts on exact generated values needs re-recording after an upgrade. The project's own test scripts use vitest, and the package exposes a test:update-snapshots script, which is the mechanism a project would mirror for its own snapshots.

The README describes Faker as an MIT-licensed open source project, and the repository carries a LICENSE file. The repository metadata reports the licence as NOASSERTION, which is a classification result rather than a statement about the licence text; read the LICENSE file itself before relying on it. Nothing here is legal advice.

Editorial conclusion

Adopt Faker when you need large volumes of plausible fixtures in TypeScript or JavaScript and want a seeded, locale-aware generator. Do not adopt it for production data, for referentially consistent records across runs without saving the seed, or as a substitute for a database anonymization tool. Before wiring it into a test suite, check which locale modules actually carry data for the fields you use, and confirm on fakerjs.dev which documentation version matches the release you install, because the repository's default branch is next while the stable docs describe v10.

Frequently asked questions

Official sources

1. faker-js/faker on GitHub
2. Issues
3. Project website
4. README
5. Releases