Real Fake Data

The VS Code extension is live:
code --install-extension przeslijmi.real-fake-data

Ctrl+Shift+P, pick a generator, and the record lands where you were typing. Three cursors and a batch of three gives each cursor its own record. No account, no key, no signup — without an API key it runs on the anonymous lane, so it works the moment it installs.

That is a REVOLUTION in how You reach for test data!!!

See: https://real-fake-data.com/vscode/

The multi-country endpoints (/v1/person-name, /v1/company-name, /v1/offering) were still EU-only while the US and Canada shipped underneath them. Now all four span the same 29.

Nothing new was built — the pools existed and simply weren't wired up. Which is its own small lesson about shipping fast: the gap wasn't in the hard part.

One thing to know before you upgrade a fixture: /v1/offering is no longer single-currency. American offerings are quoted in USD, Canadian in CAD, and prices are not rate-converted, so an unqualified batch now mixes EUR, USD and CAD.

We could have hidden that behind a conversion rate and handed you a tidy number that was wrong. Every record has always carried its own currency field — read it, or pin countries to keep a test in one currency.

No Pro tier. No subscription. 1,000 tokens a month with no account at all, 2,000 with a free one, renewed on the 1st — then prepaid credits that never expire if you need more.

And every feature on every tier. Compose, edge, extreme, invalid: none of it is behind anything.

The reasoning, because the announcement isn't the interesting part: gating capability makes a testing tool worse at its only job. If someone can't run the exact thing that proves the value, they don't evaluate you — they bookmark you. Volume is the honest thing to charge for, because volume is the thing that actually costs us money.

Paying buys volume, never capability. You can check that in thirty seconds, which is the whole point.

Teaching QA, testing or backend development? We issue a batch of one-time codes for your course — one per student, redeemed on their own account, so their work stays theirs after the course ends and the credits don't expire once redeemed. Including after they graduate.

A code works exactly once, so a leaked handout costs one grant. No payment details at any stage, not to sign up and not to redeem.

The bit I want to be clear about: this is the same product, not a teaching edition. Every generator, every country, edge, extreme, invalid, compose. Paying here only ever buys volume.

Eleven more generators, and almost every American assumption goes the other way.

Where the SSN and EIN carry no checksum, the SIN and Business Number are both Luhn-checked — genuinely verifiable, so invalid=true breaks real arithmetic instead of merely violating a range. Where the US has no account-number standard, Canada has CPA Standard 006, fixed at 7 or 12 digits.

My favourite piece of real-world mess: the transit number is returned in both renderings — XXXXX-YYY as printed on a cheque, 0YYYXXXXX for electronic transfer — and the field order reverses between them. A system that accepts one routinely chokes on the other. That's a production bug somewhere right now.

Bilingual throughout: Ltée and ULC beside Inc., plates for all 13 provinces and territories, and QC / Quebec / Québec all resolving to the same place.

Eleven generators for the United States — SSN, EIN, ABA routing number, bank account, plates for 51 jurisdictions, whole person and company.

Building this taught me more about European identifiers than building the European ones did. A PESEL or a Danish CPR encodes your birth date and sex. An SSN encodes neither — and since the SSA randomised assignment in 2011, not a state either. It has no check digit at all, so no arithmetic on earth can tell you whether one is plausible.

So /v1/us/ssn offers no sex or age filters, because it would be lying. /v1/us/company carries only an EIN, because US incorporation is a state matter with no federal registry. And the bank account is split honestly: the routing number is a real standard with a real 3-7-1 mod-10 checksum, while the account number has no national standard whatsoever — 4 to 17 digits, each bank's own choice, nothing to validate against.

A tool that "validates" all of these the same way is lying to you. Refusing to is the feature.

POST /v1/compose. Every other endpoint returns one field; this one returns your whole schema, filled in.

You send the nested JSON shape your app expects and mark each slot with a $-source. $count turns any node into an array — a fixed number, or a [2, 5] range that rolls per parent, so 100 orders each get their own 2–5 items. Declare an entity once and several fields describe the same person: a buyer whose name, PESEL and email agree.

The part I'm most pleased with is the dates. $anchor measures a child from its own parent's field, so every order lands after the customer who placed it and every shipment after its order. Fixture data where a post predates its author's signup is the standard, and it quietly invalidates every test that touches a date range.

Whole thing reproducible from one seed.

WOW https://real-fake-data.com

Two small generators, /v1/enum and /v1/object: a weighted draw over values, or over whole JSON objects. choices={"gold":1,"silver":4,"bronze":15} and you get the skew you asked for.

The genuinely unusual bit: under edge, the distribution inverts. Your rarest tier becomes the most likely, and a member with weight zero shows up at all.

Which means you can finally test the cohort your seed data never produces enough of. You have four gold-tier customers in staging and you have never once tested the gold-tier path.

extreme=true on every generator that already took edge. Untrimmed and non-breaking whitespace, zero-width characters with a leading BOM, homoglyphs (Cyrillic and Greek lookalikes that read as Latin), RTL overrides and stacked combining marks — one class per record, rotating across a batch.

The question it exists to answer: does your pipeline trim, normalise and compare safely, or does a zero-width space break an equality check and a homoglyph slip past a filter?

The constraint that made it usable: identifiers stay ASCII-clean. Your PESEL still checksums after normalisation. Only the human-facing string gets mangled, and it stays recoverable.

UUID (v4 and v7), ULID, Nano ID, MongoDB ObjectId, and an auto-increment sequence. The primary keys — technical identifiers no national registry issues but every record needs.

The detail worth stealing: any embedded timestamp derives from the seed, not the wall clock. A seeded UUID v7 is reproducible, which makes it better than a real random one for fixtures.

At the time this felt like housekeeping. It was the missing ingredient for the feature that came a few weeks later.