Stop Typing "test@test.com" — Fill Any Form in One Click with FillKit

Justin Dah-kenangnon — Wed, 29 Apr 2026 05:45:41 +0000

Every developer has been there. You're wiring up a new registration flow, spinning through a QA checklist, or demoing a feature to a stakeholder — and you find yourself typing the same fake name, the same throwaway email address, and the same placeholder phone number for the forty-seventh time that week.

It is not a workflow problem. It is a friction tax — invisible, constant, and entirely eliminable.

FillKit is a free, open-source browser extension that removes that tax entirely. One click. Every field filled. Context-aware, locale-correct, realistic data — generated locally, with no account required and no data leaving the browser.

What FillKit Actually Does

FillKit is a browser extension that introspects the DOM of any web page, identifies form fields by type and semantic context, and populates them with statistically plausible, structurally valid data. No manual field mapping. No schema files. No configuration ceremony.

The intelligence lives in its semantic field detection engine — a TF-IDF cosine similarity model that infers what each field expects from its label text, name attribute, id, placeholder, autocomplete hints, and surrounding DOM context. A field labeled "Date of birth" gets a valid past date. A field with autocomplete="tel" in a French locale gets a properly formatted French mobile number. A password field gets a string that satisfies typical complexity rules.

The data is generated entirely client-side using @fillkit/core, the open-source engine underpinning the extension, built on top of Faker.js with locale-specific overrides and field-type heuristics layered on top.

Install in One Click — All Three Browsers Supported

FillKit is available for free across all major Chromium-based browsers and Firefox:

🟢 Chrome → Add to Chrome — Free
🔵 Microsoft Edge → Add to Edge — Free
🦊 Firefox → Add to Firefox — Free

No sign-up. No extension permissions beyond the active tab. Uninstall cleanly with zero residual data.

The Developer-Facing Features That Matter

1. Zero-Config Field Detection

FillKit does not require annotating your HTML with custom attributes or wiring a schema. The detection engine resolves field intent at runtime. This means it works on forms you did not build, on third-party SaaS dashboards, on legacy codebases with no semantic markup hygiene whatsoever.

This is architecturally significant: the extension treats the DOM as an inference target, not a configuration artifact.

2. 50+ Locale Support

Data generation is locale-aware. Switch to fr_FR and phone numbers follow French mobile formatting (06 XX XX XX XX). Switch to pt_BR and CPF-like document numbers appear in the right fields. This is not cosmetic — locale-mismatched data is a common source of validation failures in internationalization testing.

Supported locales cover all UEMOA/Francophone West African contexts, European regions, North and South America, East Asia, and more.

3. Valid / Invalid Mode Switching

The extension exposes a mode toggle for generating:

Valid data — structurally correct, passes standard validation rules
Invalid data — format violations, boundary overflows, empty where required

This makes it a practical tool for negative-path QA — the category of testing that developers routinely deprioritize because populating the forms manually to reach those states is tedious.

4. Pinned / Fixed Values

Specific fields can be locked to a fixed value while the rest of the form generates randomly. The canonical use case: pin email to your own address during a demo so confirmation emails arrive in a real inbox, while everything else fills automatically.

5. The npm Package — `@fillkit/core`

For teams who want programmatic access to the data generation engine:

npm install @fillkit/core

import { FillKit } from '@fillkit/core';

const fk = await FillKit.init({ mode: 'valid', ui: { enabled: true } });
await fk.autofillAll(); // Fill all forms

This enables integration into Playwright, Cypress, or Puppeteer test suites where synthetic realistic data is needed without hardcoding fixtures.

The Open-Source Architecture

The full implementation is public on GitHub under the fillkit organization. The separation of concerns is clean:

Layer	Package	Role
Core engine	`@fillkit/core`	Field detection, locale-aware data generation
Browser extension	`github.com/in-browser` (Chrome/Firefox)	DOM traversal, UI, popup, content script
SDK	`@fillkit/sdk`	Headless API for programmatic use

All data is generated in-process, in the browser. No telemetry. No analytics. No outbound requests. The privacy policy is structurally simple: there is nothing to collect.

Practical QA Workflows This Unlocks

Multi-step registration testing: Fill a 5-step onboarding wizard in under 10 seconds per pass. Vary locale and data mode across passes to cover happy path, edge case, and invalid input branches without maintaining fixtures for each.

Staging environment hygiene: Eliminate test123, asdf@asdf.com, and John Doe from staging databases. Team-generated data is statistically realistic, which makes database queries, analytics dashboards, and search relevance tests meaningful rather than degenerate.

Demo preparation: Fill a CRM contact form with a realistic prospect record in one click before a screen-share. The data is plausible to observers — no "AAAA BBBBB" visible in demo recordings.

Internationalization regression: Switch locale, refill, and verify that date pickers, phone formatters, and address decompositions (separate street/city/postcode fields vs. freeform) handle locale-specific data correctly.

Why This Is Not Just Another Form Autofiller

Browser-native autofill (Chrome, Safari, Firefox) is built around personal data persistence — it stores and replays your own information. Password managers extended this with credential fields. Both are oriented toward end-user convenience in production.

FillKit's design axis is orthogonal: it is oriented toward developer efficiency in non-production environments. The data is synthetic by design. The locale switching is deliberate. The invalid-data mode has no analogue in any autofill system. The npm package has no analogue in any consumer extension.

It is, in effect, a test data generation tool delivered as a browser extension — meeting developers at the workflow layer where the friction actually lives.

What Is Coming: FillKit Cloud

The extension and SDK are the OSS foundation. We are building FillKit Cloud — shared team configurations, managed API access, and synchronized test data profiles across environments. A waitlist is open at fillkit.dev/#waitlist.

Get It Now

Browser	Link
Chrome	chromewebstore.google.com — FillKit
Edge	chromewebstore.google.com — FillKit
Firefox	addons.mozilla.org — FillKit
npm	@fillkit/core
Source	github.com/fillkit/sdk
Docs	github.com/fillkit/sdk#readme
Demo	demo.fillkit.dev

The extension and SDK are open source. All data is generated locally — no real user data is collected.*

I built a better documentation site for oidc-provider

Justin Dah-kenangnon — Mon, 06 Apr 2026 11:04:45 +0000

While building a production-ready OpenID Connect server with oidc-provider, I ran into a recurring issue:

👉 the documentation is powerful, but not easy to navigate.

So I built this:

🔗 https://oidc-provider.dev/

The problem

oidc-provider has excellent documentation, but it is:

spread across multiple files (README, docs/, events, changelog)
not easily browsable
hard to search or explore progressively

This makes onboarding and day-to-day usage slower than it should be.

The solution

I created a dedicated documentation site that is:

📚 fully browsable (multi-page navigation)
🔍 searchable
🧭 easier to explore than raw Markdown
🗂 structured by topics

Always in sync with upstream

The key design constraint was:

never diverge from the official documentation

So the site is:

automatically generated from official sources:
- README
- docs/*
- CHANGELOG
- events.md
continuously synced via GitHub Actions

Any update in the upstream repository is reflected automatically.

Why this matters

oidc-provider is a low-level, spec-compliant implementation.

That means:

a lot of behavior is driven by specs
documentation is dense and technical
discoverability is critical

This site aims to improve:

onboarding speed
feature discoverability
overall developer experience

What’s next

Planned additions:

real-world configuration examples
deployment patterns
integration guides

Feedback

If you are using oidc-provider, feedback is highly valuable.

The goal is to make the ecosystem easier to approach without altering its philosophy.

DEV Community: Justin Dah-kenangnon

Stop Typing "test@test.com" — Fill Any Form in One Click with FillKit

What FillKit Actually Does

Install in One Click — All Three Browsers Supported

The Developer-Facing Features That Matter

1. Zero-Config Field Detection

2. 50+ Locale Support

3. Valid / Invalid Mode Switching

4. Pinned / Fixed Values

5. The npm Package — `@fillkit/core`

The Open-Source Architecture

Practical QA Workflows This Unlocks

Why This Is Not Just Another Form Autofiller

What Is Coming: FillKit Cloud

Get It Now

I built a better documentation site for oidc-provider

The problem

The solution

Always in sync with upstream

Why this matters

What’s next

Links

Feedback

DEV Community: Justin Dah-kenangnon

Stop Typing "test@test.com" — Fill Any Form in One Click with FillKit

What FillKit Actually Does

Install in One Click — All Three Browsers Supported

The Developer-Facing Features That Matter

1. Zero-Config Field Detection

2. 50+ Locale Support

3. Valid / Invalid Mode Switching

4. Pinned / Fixed Values

5. The npm Package — @fillkit/core

The Open-Source Architecture

Practical QA Workflows This Unlocks

Why This Is Not Just Another Form Autofiller

What Is Coming: FillKit Cloud

Get It Now

I built a better documentation site for oidc-provider

The problem

The solution

Always in sync with upstream

Why this matters

What’s next

Links

Feedback

5. The npm Package — `@fillkit/core`