jaswdr/faker: fake data for Go tests, seeds and demos

The problem faker solves: populated data without a dependency tree

Nearly every service needs a database that is not empty when a developer runs it locally, and every test suite needs rows that look like production without containing production data. Writing those fixtures by hand is dull; pulling in a library that generates them can be worse when that library drags in a dozen transitive modules. jaswdr/faker takes the second route while keeping the first clean: the repository description calls it an ultimate fake data generator for Go with zero dependencies, and the go.mod file confirms it, declaring only the module path and the Go version with no require block at all.

The use cases the README names are concrete rather than abstract: bootstrapping a database, creating good-looking XML documents, filling in your persistence to stress test it, and anonymizing data taken from a production service. That last one deserves emphasis. Anonymizing real records is a different requirement from generating random ones, because the output has to keep the shape and plausibility of the input while dropping the real values, and a provider catalogue spanning people, addresses, payments and messages is what makes that possible without writing a masking layer per table.

The library is heavily inspired by PHP's Faker, and it carries that design across to Go. The generator is created once and then accessed through properties named after the kind of data you want, which reads naturally in Go and keeps call sites short.

Installing faker and creating your first generator

Installation is a module path and a go get, nothing more:

import "github.com/jaswdr/faker/v2"

The README's instruction is to add that import to your Go file and then run go get to fetch the package. The /v2 suffix matters for module resolution, since the project moved to semantic versioning and Go requires the major version in the path for v2 and above.

The first program creates a generator with faker.New() and then reaches into providers by name:

import "github.com/jaswdr/faker/v2"

func main() {
    fake := faker.New()

    fake.Person().Name()
    // Lucy Cechtelar

    fake.Address().Address()
    // 426 Jordy Lodge

    fake.Lorem().Text(100)
    // Dolores sit sint laboriosam dolorem culpa et autem. Beatae nam sunt fugit
    // et sit et mollitia sed.
    // Fuga deserunt tempora facere magni omnis. Omnis quia temporibus laudantium
    // sit minima sint.
}

Two behaviours are worth reading off that example. First, the access is a chain of two calls: the provider method returns a value, and every call to fake.Name() yields a different random result, so you call the provider once and use it repeatedly rather than caching a single string. Second, the Lorem provider takes a length argument and returns prose, which is what makes it usable for filling text columns and XML documents rather than only for placeholder words.

A loop over one provider shows the variety in practice:

p := fake.Person()

for i:=0; i < 10; i++ {
  fmt.Println(p.Name())
}
  // Adaline Reichel
  // Dr. Santa Prosacco DVM
  // Noemy Vandervort V
  // Lexi O"Conner

The names include titles and suffixes alongside the plain given name and family name, which matters when your database has a name column that must survive truncation and casing rules.

Filling structs from tags with f.Struct()

The Struct provider is the feature that turns faker from a convenience into a fixture tool. You define your model as usual and add fake tags where you want generated values:

type ExampleStruct struct {
	SimpleStringField string
	SimpleNumber int
	SimpleBool bool
	SomeFormatedString string `fake:"??? ###"`
	SomeStringArray [5]string `fake:"????"`
}

example := ExampleStruct{}
f.Struct().Fill(&example)
fmt.Printf("%+v", example)
//{SimpleStringField:87576a01c2a547b2bbf9b7c736d1db40 SimpleNumber:9223372036854775807 SimpleBool:false SomeFormatedString:cxo 321 SomeStringArray:[effr swxp ldnj obcs nvlg]}

The tag syntax uses the question mark as a placeholder character, so ??? ### produces three letters, a space and three digits, while ???? fills the array elements with four letters each. Untagged fields are filled according to their type, which is why the plain string field receives a hex-looking value and the int field receives the maximum int64. The provider also offers FillWithDepth for nested structures and RegisterFunction for custom generators, which is the hook you need for a column that has to look like your own domain rather than a generic placeholder.

The trade-off to note is that Fill works on reflection and tags, so it needs the fields to be exported and the values to be settable through reflection. A struct with unexported fields, or one built from a constructor that validates invariants, will not be filled the way you might hope. The README does not document those limits, so they are worth checking against your own model types.

Reading the provider catalogue: what you get out of the box

The README tabulates the providers, and the table is the best single view of the library's scope. Access is always the same shape, f.<Provider>().<Method>().

Identity and contact come first. Person() gives Name, FirstName, LastName, SSN, Contact and Image. Address() gives Address, City, State, ZipCode, Latitude and Longitude, described as US-style addresses. Phone() gives Number, E164Number and TollFreeNumber. Internet() covers Email, URL, IPv4, IPv6, Password and UserAgent.

Business and payment data follow: Company() with Name, CatchPhrase, JobTitle and EIN, and Payment() with CreditCardType, CreditCardNumber and CreditCardExpirationDateString. For time and identifiers there is Time() with Recent, Past, Soon, Future, ISO8601 and RFC3339, and UUID() with V4. Color() produces Hex, RGB and SafeColorName, and File() and Directory() produce Extension, Path and AbsolutePath for filesystem-shaped strings.

The tail of the catalogue is where the library gets distinctive. Crypto() provides BitcoinAddress and EthereumAddress, and there are specialty datasets for Beer, Car, Food, Pet, Gamer, Pokemon, Music and YouTube, each with its own set of methods. The repository's flat file listing confirms the shape of this: beer.go, car.go, food.go, gamer.go, blood.go, currency.go, emoji.go, hash.go, genre.go, gender.go and a data directory, each with a matching test file.

On the Faker object itself sit the formatting helpers that most of these providers build on: Numerify, Lexify, Bothify, Asciify, IntBetween, Bool and BoolWithChance. Lexify replaces characters with letters, Bothify does letters and digits, and BoolWithChance takes a probability, which is how a fixture generator can be told to make a field occasionally true.

Image providers that reach out to the network

Three separate providers produce images, and they work differently from each other. LoremFlickr pulls random images from a photo service, returning a file pointer to a locally written image:

// get a *os.File pointing to a file that is a random image
image := f.LoremFlickr().Image(100, 100, []string{}, "", false)

fmt.Println(image.Name())
// /tmp/loremflickr-img-4101493944.jpg

ProfileImage() does the same thing against a service that generates a face:

profileImage := f.ProfileImage().Image()

fmt.Println(profileImage.Name())
// /tmp/profil-picture-img-4022222298.jfif

The third, Image() on the person provider, generates a placeholder profile picture locally and reports a path in the temporary directory.

The distinction matters operationally. The two remote providers make network calls to third-party services, which makes tests that use them dependent on someone else's uptime and on the machine having outbound access. A test suite that calls ProfileImage().Image() in a sandboxed CI runner will fail for reasons that have nothing to do with your code. The README does not describe any timeout, retry or caching behaviour for these calls, and it does not document a way to substitute a local source, so the safer design is to keep these providers out of unit tests and use the local Image() provider or your own fixture files there.

The README also points to the package documentation on pkg.go.dev for more formatters, which is where the full method list for each provider lives.

Go version policy, versioning and what the release history shows

The README is explicit about the supported toolchain. Faker requires Go >= 1.22 for 2.X, and the go.mod file in the repository declares go 1.22 alongside the module path github.com/jaswdr/faker/v2. Maintenance follows the Semantic Versioning guidelines, and the README spells out what that means in practice: starting at 2.X, only maintained versions of Go are supported, which according to Go's release policy means only the two newer major versions. A project that cannot move its toolchain every couple of years cannot follow this library across major versions.

The release history shows a steady cadence. Version 2.9.0 was tagged on 2025-11-08, 2.9.1 on 2025-12-05, and 2.10.0 on 2026-09-24. The last push to the repository was on 2026-09-24, the same day as that release, and the repository is not archived, so the project is still receiving work.

Two limits are worth stating plainly. The data catalogue is US-centric by design, since the address provider is described as producing US-style addresses, and there is no locale parameter in the provider list, so a German or Japanese deployment will get American street names unless you supply your own data. The library is also not reproducible by default: the README says each call yields a different random result and documents no seeding mechanism, so tests that assert on generated values will be flaky unless you avoid asserting on them or control the randomness yourself.

The licence is MIT, and the README points to the bundled LICENSE file for the details. The project is created and maintained by Jonathan Schweder and a group of contributors, and the repository carries a code of conduct, a security policy, a Gitpod configuration and a set of code quality services wired into its continuous integration.

When to reach for something else instead

There are two cases where faker is the wrong tool, and one where the alternative is worth understanding.

The first wrong case is international data. Because the address provider is explicitly US-style and the person catalogue is built around US naming, a product serving other locales will end up hand-writing provider data anyway. Writing your own dataset files and calling the core helpers Numerify, Lexify or Bothify is often less work than bending the built-in catalogue.

The second wrong case is a hard requirement for deterministic output. The README documents randomness as the default behaviour and no seeding interface, so a test that needs the same data on every run has to bypass the library.

The interesting alternative is PHP's Faker, which the README names as the source of the design. The difference in approach is that PHP's Faker is an object-oriented runtime library with provider classes per locale, and the Go port keeps the provider-per-domain shape while compiling everything into a single dependency-free module. Practically that means the Go version drops the locale dimension, drops the reflection-heavy factory in favour of a concrete faker.New() returning a struct of providers, and gains the ability to run in a service binary without pulling anything in. If your team already knows the PHP library, the API shape will look familiar, but the locale coverage does not carry over.

For very simple cases, the standard library's own random helpers are the honest comparison: a handful of lines with math/rand produce unique names and numbers. The point at which faker earns its place is breadth, when a fixture needs addresses, payment cards, crypto addresses and text in the same pass, or when struct tag filling has to maintain your model's shape for you.

Editorial conclusion

jaswdr/faker is the right pick when a Go service needs believable filler data for tests, seed scripts or demos and you would rather not add a dependency tree to the module. It is the wrong pick for applications that need names and addresses outside the US-style catalogue, for pipelines that must be reproducible from a fixed seed, and for environments with no outbound network access if you intend to use the LoremFlickr or ProfileImage providers. Verify first that the fields your models need are covered by the provider list, and that image generation is acceptable in your build and test environment before wiring it into a fixture.

Frequently asked questions

Official sources

1. jaswdr/faker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases