FormForge — Form Filler & Autofill for QA Testing

FormForge fills web forms with realistic test data in one click — including the React, Vue and Angular forms that ordinary autofill silently fails on. Built for QA engineers, developers and testers who fill the same form fifty times a day. Everything runs on your own machine: no account, no cloud, no AI, and no network requests of any kind. Whether you call it test data, dummy data or fake data, the job is the same — a form full of values that are plausible enough to submit, generated fresh every time. WHY NOT JUST USE AUTOFILL Browser and password-manager autofill are built for one person filling in their own details. That is the opposite of what testing needs. They fill your real name, your real address and your real email, they only offer to fill fields they recognise as yours, and they leave everything else blank. Run them twice and you get the same person twice, so you cannot tell one test signup from another. FormForge generates a new fictional person on every fill, fills every field on the form rather than the handful autofill recognises, and never touches your saved personal data because it does not have access to it. If you have ever wondered why autofill does nothing on a particular form, the answer is usually that the form is built with a framework that discards the value, or that the fields are not the ones autofill knows how to name. Both cases are what FormForge is for. WHY ANOTHER FORM FILLER Most form fillers work on a simple login page and quietly fail on a real application. FormForge is built around the cases that break the others: • React, Vue and Angular controlled inputs — values are written through the native property setter and the framework's own change tracking, so your app actually registers the input instead of discarding it on the next render. • Shadow DOM, including nested shadow roots and custom elements. • react-select and similar custom dropdowns, including the type-to-search kind where you must type before any option appears. • Native multi-selects. • Same-origin iframes. • Rich-text editors and contenteditable regions — text is inserted using the browser's own editing command rather than by overwriting the element's content, so an editor that keeps its own internal model stays in step with what is on screen. • Field names containing dots, dashes and other characters that break naive selector matching. One limit worth knowing before you install: a form inside a CROSS-ORIGIN iframe is not filled, and cannot be. Reaching into another site's frame would require standing access to that site, which FormForge deliberately does not ask for. Same-origin frames fill normally. REALISTIC DATA, NOT RANDOM STRINGS A random string in a phone field just fails validation. FormForge reads each field's type, label, placeholder, ARIA attributes and autocomplete token, then generates something that fits: • Names, addresses and phone numbers in English, German, French, Spanish and Portuguese, with separate data for Portugal and Brazil — matched to the page's own language automatically, with a sensible fallback when the page does not say. • Numbers that respect min, max and step. • Dates inside the field's own allowed range — and dates that make sense for the field they are in. A date of birth lands in the past, a delivery date in the future, a joined date behind today. A field is not just a date format, it is a meaning. • Luhn-valid test card numbers. • One consistent fictional person per fill, so the filled form reads like a real submission rather than a bag of unrelated values. • Email prefix — set a prefix like "qa" and every generated address becomes qa+4821@yourdomain.com, so all your test signups land in one inbox you control. • Values that FIT a field's maxlength by choosing a narrower format — a 10-character mobile field gets 5551234567, never a clipped "(555) 123-". The same applies to short postcode and date fields. Address and email fields are told apart rather than treated as one kind. A billing address, a shipping address and a current address get different addresses. A user email and a customer email are not assumed to be the same person's. Free-text boxes get language that fits the field — a delivery-notes box reads like a delivery note, a bio like a bio. No lorem ipsum: you can look at a filled form and tell at a glance whether it is plausible. Set a seed (Pro) and you get identical data every run on the same version, so a failing regression run can be replayed with exactly the same values. HOW IT DECIDES WHAT A FIELD IS Most fillers match on the name attribute and give up when it is unhelpful. FormForge reads every signal the field offers and weighs them: • A visible label, including one that wraps the input rather than pointing at it. • aria-labelledby, for fields labelled by another element entirely. • The placeholder, when there is no label at all. • The autocomplete token. • The name and id, segmented on camelCase and on dots, dashes and underscores. When the label and the id disagree, the label wins. A field with id "userName" and a label reading "Full Name" gets a full name, because that is what the person filling the form is being asked for. Field names are read in five languages, not only English. First name, surname, street, city, postcode, country, phone and email are recognised by many of their German, French, Spanish and Portuguese names and labels, and so is a date of birth. A few short words are deliberately left out because they are also ordinary English and would misfire on English forms — German "Land" and French "Pays" for country, and French "portable" for a mobile number. Every other field type is matched on its English name. IT NEVER TOUCHES WHAT IT SHOULDN'T CAPTCHA fields, hidden inputs, disabled and readonly fields, file pickers and anything genuinely invisible are left strictly alone. Required checkboxes are always ticked, because a form that cannot submit is not filled, and…