How to Fill Forms With Localized Test Data in 60+ Languages (Names, Addresses, Phones)
Testing a multilingual app means filling forms with locale-correct names, addresses, and phone numbers — not English data with accents bolted on. Here's how to generate localized test data for any web form, in 60+ languages, without building a spreadsheet per market.

If you test a product that ships in more than one language, you already know the chore: every signup, checkout, and address form has to be filled with data that looks right for each market. A Japanese name in kanji. A German street address with the house number after the street. A French phone number that starts +33. A Brazilian name with a tilde in it.
English test data with a couple of accents pasted in doesn't catch the bugs. The bugs live in the real shapes — the field that truncates kanji, the validator that rejects a 9-digit local number, the address line that assumes a US ZIP. To find those, you need localized test data: values generated to each locale's actual conventions.
This guide is about getting that data into your forms quickly — without hand-building a spreadsheet for every language you support.
What "localized test data" actually means
It's not translation. It's data shaped to a region's real conventions. For a typical form, that's:
- Names with the right script and characters —
ü,ñ,é, kanji, Cyrillic, Arabic — not Latin names with a diacritic sprinkled on. - Addresses in the local format — street/number order, postal-code shape, and the fields a country actually uses.
- Phone numbers with the correct country code and local grouping, not a US 10-digit pattern everywhere.
- Dates, currency, and numbers that exercise each locale's separators and formats — the things that quietly break parsing and sorting.
The reason this matters: most internationalization (i18n) defects come from the shape of the input, not the translated label above it. A form that works fine with John Smith falls over on José Müller or 田中 太郎. You only see it if you fill it with data that looks like that.
Why the usual ways are slow
Most teams reach for one of these, and each has a catch:
- A spreadsheet per locale. Accurate, but you build and maintain one by hand for every market. It's the single biggest time sink in localization testing, and it goes stale.
- Google Translate the English data. Translates words, not formats. You get translated text in a US address shape — which is exactly the case that hides the bug.
- A random / fake-data filler. One click fills the form, but the data is English-only. Most random fillers (Fake Filler and similar) have no concept of locale, so they can't produce a kanji name or a
+49number at all. - A faker script in code. Libraries like Faker.js do generate locale-aware data — but you're writing and running code, exporting files, and pasting values into the browser by hand. It's not a fill-the-form-in-front-of-you workflow.
The gap is the same one every time: there's no quick way to drop locale-correct, realistic data straight into the form you're looking at, switch the language, and go again.
The faster way: pick a language and fill — no setup
This is what Fillr is built for, and the core of it takes no configuration at all.
Open the side panel, pick a language, click fill. On any form, open the Fillr side panel, choose your locale from the list — English, Japanese, German, French, Portuguese, Arabic, and 60+ in total — and hit fill. Every field gets realistic data generated for that locale: the name in the right script, the address in the local format, the phone with the right country code. No preset, no spreadsheet, no code. Switch the locale, fill again, and the same form is populated for the next market. That's the whole loop.
The generated values draw from 120+ data types — names, emails, street addresses, phone numbers, IBANs, company names, and more — each one locale-aware. So a full multilingual pass on a form is: pick a language, fill, switch, fill — a few clicks per market.
Want it the same way every time? Save a preset (optional). If you test a form often and want control over individual fields, capture it once as a preset. Then each field gets a rule — Generate a realistic value, use a Fixed value, leave it Blank, Skip it, or pull it from your own data — and the preset surfaces automatically next time you land on that page. This is for repeatability and per-field control; you don't need it just to fill in another language.
Need exact records? Drive it from your own rows (optional). Generated data covers "give me a realistic German address." When you need specific localized records — a known list of edge-case names, the exact Turkish phone format that broke production — import them as a dataset (CSV, Excel, or JSON), link it to a preset, and fill row by row. Sequential mode shows "row 3 of 20," so when a locale-specific bug appears you know precisely which record caused it. That's reproducibility, the thing a random filler can't give you.
Walkthrough: fill a form in another language, step by step
- Install the extension and open the form you want to test — a signup, checkout, or address form.
- Open the Fillr side panel and pick a locale — say, Japanese.
- Click fill. The name fills in kanji, the address in Japanese format, the phone with
+81. No preset needed. - Switch the locale to German and fill again. Same form, now populated for the German market.
- Repeat for every language you ship. Each fill is one click with locale-correct data.
That's the whole flow. Two optional add-ons when you want more:
- Save it as a preset if you test the form often and want a saved rule per field.
- Import a dataset of your own localized rows and fill sequentially — with a "row N of M" readout so every submission is a known case.
Side-by-side: ways to get localized test data into a form
| Spreadsheet per locale | Google Translate | Random / fake fillers | Faker script | Fillr | |
|---|---|---|---|---|---|
| Locale-correct names (scripts, diacritics) | ✅ manual | ⚠️ translated, wrong shape | ❌ English only | ✅ | ✅ |
| Local address & phone formats | ✅ manual | ❌ | ❌ | ✅ | ✅ |
| Fills the form in front of you | ❌ copy-paste | ❌ copy-paste | ✅ | ❌ export first | ✅ |
| Switch language without rebuilding data | ❌ | ❌ | ❌ | ⚠️ re-run code | ✅ one click |
| Number of languages | however many you build | any (text only) | usually English | 60+ | 60+ |
| Fill from your own exact records | ✅ | ❌ | ❌ | ⚠️ via code | ✅ row by row |
| Reproducible ("which row was that?") | ⚠️ manual | ❌ | ❌ | ⚠️ | ✅ "row 3 of 20" |
| No code required | ✅ | ✅ | ✅ | ❌ | ✅ |
No single built-in tool spans "locale-correct data," "drop it into this form," and "switch language in one click." That combination is the gap localization testers keep hitting.
FAQ
How do I generate test data in different languages? Use a form filler with locale-aware generators. In Fillr, open the side panel, pick a locale, and click fill — every value (names, addresses, phones) comes out in that language's real format. No preset, spreadsheet, or code; switch the locale to change the whole fill.
What's the difference between localized test data and translated test data? Translation changes the words. Localized test data changes the shape — the script a name uses, the order of an address, the country code on a phone, the separators in a number. Most i18n bugs come from shape, so translated English data in a US format usually misses them.
Can I test a form with non-Latin characters like kanji or Arabic? Yes. Pick the matching locale (Japanese, Arabic, and 60+ others) and generated names and text come out in the correct script — the input you need to check that fields, validation, storage, and export all round-trip Unicode correctly.
Can I use my own localized records instead of generated data? Yes. Import a CSV, Excel, or JSON file of your own rows as a dataset, link it to the form's preset, and fill row by row. Sequential mode shows "row N of M" so every locale-specific case is reproducible.
Do random form fillers support other languages? Most don't — they fill with English data and have no locale setting, so they can't produce a kanji name or a non-US phone format. That's the main reason testers outgrow them for localization work.
Does it work on internal tools and staging sites? Yes — any web form, including admin panels, internal apps, and localhost/staging. URL patterns match your environments, and nothing is installed on the site itself.
The short version
Localization testing breaks on the shape of the data, not the translation. To catch those bugs you need locale-correct names, addresses, and phone numbers in the actual form — and you need to switch languages without rebuilding a spreadsheet each time.
That's what Fillr gives you with no setup: open the side panel, pick one of 60+ languages, and click fill — realistic, locale-correct data dropped straight into the form. Save a preset or bring your own rows when you want per-field control and reproducibility. Add it to Chrome and fill your next form in any language in one click.