FIRST CH TOOLS LOCAL PROCESSING — NOTHING IS SENT TO A SERVER 日本語

FIRST CH TOOLS / 13 TEST DATA GENERATOR

Test Data Generator

Dummy data for form testing, CSV import testing and upload testing. Generates names, kana readings, addresses, postal codes, emails and phone numbers as CSV / TSV / JSON / Excel (.xlsx), with a choice of encoding (UTF-8, UTF-8 with BOM, Shift_JIS) and line endings. It also builds exact-length boundary strings — full-width, half-width katakana, emoji, platform-dependent and zero-width characters — and dummy files of an exact byte size.

Dummy records (CSV / TSV / JSON / Excel)

How to Use

  1. Pick a tabDummy records (CSV/TSV/JSON/Excel), boundary-length text, or a dummy file of an exact byte size.
  2. Set the conditionsColumns, row count and encoding (UTF-8 / BOM / Shift_JIS, LF/CRLF); character type and length; or size and extension — whatever the receiving end expects.
  3. Copy or downloadPaste straight into a form, or save the file for an import or upload test. Note the seed down and you can reproduce the exact same data later.

About This Tool

Testing a contact form or signing off a CSV import usually means inventing throwaway data on the spot. This tool generates the fields we actually check on client projects (name, kana reading, address, postal code, phone) and puts the things that break in Japanese-language environments — encoding, line endings and character-type boundaries — in the same place.

Everything it produces is fictional. Names come from common name lists, addresses combine a real town name with a randomised block number, and email addresses use example.com / example.net / example.org — domains reserved by RFC 2606 that can never receive mail. English phone numbers use the 555-0100–555-0199 range reserved for fictional use. Japan has no reserved fictional range, so a randomly generated Japanese number may coincide with a real one — use it for display and import testing only, never for actual calls or SMS.

The free-text column deliberately includes sentences with commas, quotes and line breaks, so you can confirm that RFC 4180 quoting is handled correctly. Shift_JIS output is produced by building a reverse lookup table from the browser's own TextDecoder, so no conversion table has to be downloaded. Characters that Shift_JIS cannot represent (emoji, for example) become ? and the count is reported as a warning.

Choosing Excel (.xlsx) writes a workbook you can open directly. Every column except the serial ID is written as a text cell, so a postal code like 02108 keeps its leading zero and a value like 1-2-3 is not silently turned into a date — the two things that most often go wrong when a CSV is opened in Excel. The header row is bold with the top row frozen, and column widths are set to match the content. Encoding, BOM and line-ending options do not apply to .xlsx, whose internal XML is always UTF-8 (they remain CSV/TSV features).

The File size tab builds a file of exactly the byte count you ask for, for signing off upload limits. The output buffer is allocated at the requested length and then filled, so the size always matches. An upload-limit test is really a pair — exactly at the limit, and one byte over — so N−1 / N / N+1 are all offered as downloads. Both MiB (1,048,576 bytes) and MB (1,000,000 bytes) are available, because the “10M” in a server config and the “10MB” in a spec sheet are not the same number, and that gap is exactly what decides whether the test passes. N−1 at a size of zero gives you an empty file, which is itself worth testing.

The contents always match the extension you pick — .txt is plain text, .csv is a four-column CSV with a header row, .json is an array of objects, .bin is binary. Files whose contents disagree with their extension are deliberately not generated, given the potential for misuse. The output depends on nothing but the size and the extension, so the same request always produces a byte-identical file and can be written straight into a test procedure. The cap is 100 MiB: the file is assembled in your device's memory, so anything larger is trimmed to that.

Generation, encoding and file output all happen in your browser in plain JavaScript — no WebAssembly, no external API, nothing sent to a server. The .xlsx writer builds the ZIP container and the OOXML parts directly rather than loading a library such as SheetJS. Setting a seed makes the output reproducible, so you can record it in a bug report or a regression test (.xlsx files use a fixed timestamp, so the same seed yields a byte-identical file).

From AI Agents

Open the page with URL parameters and the result is rendered directly into the DOM. An agent that can drive a browser gets the data in a single request, without touching the form.

# 50 rows, CSV, explicit columns, fixed seed (reproducible)
/en/testdata/?rows=50&format=csv&fields=name,name_kana,email,tel,zip,address&seed=test-2026

# Excel file (.xlsx), downloaded directly
/en/testdata/?rows=100&format=xlsx&fields=id,name,email,tel,zip,address

# CSV for Excel (Shift_JIS, CRLF)
/en/testdata/?rows=20&format=csv&encoding=shift_jis&newline=CRLF

# JSON, English data, no header row
/en/testdata/?rows=5&format=json&locale=en&header=0

# Boundary text: exactly 100 characters of mixed Japanese (returns 99 / 100 / 101)
/en/testdata/?preset=mixed&len=100

# A CSV of exactly 10 MiB (10,485,760 bytes); N−1 / N / N+1 are all downloadable
/en/testdata/?size=10&unit=MiB&ext=csv

# A text file of exactly 10,000,000 bytes — the "10MB" a spec sheet usually means
/en/testdata/?size=10&unit=MB&ext=txt

Parameters: rows(1-1000) / format(csv,tsv,json,xlsx) / fields(id, name, name_kana, name_romaji, gender, birthday, email, tel, zip, address, company, department, url, text) / locale(ja,en) / encoding(utf-8,shift_jis) / newline(LF,CRLF) / bom(1) / header(0) / seed / preset / len(1-10000) / size / unit(B,KB,KiB,MB,MiB) / ext(txt,csv,json,bin) / tab(records,text,size). encoding / newline / bom are ignored when format=xlsx. All three tabs are rendered into the DOM regardless of which one is on screen.

Other Tools