How recognition works

DevFiller works out what each field is before it fills anything. It doesn't guess from one attribute: it collects every clue the page gives, weighs them, and fills a field only when the evidence is strong enough. When it isn't sure, it says so, because an unrecognized field is less harmful than a wrong one.

Everything below runs in your browser. No page content is sent anywhere to recognize a field, and there is no AI involved unless you turn on AI suggestions for the fields DevFiller can't recognize on its own.

1. Read every clue

For each field, DevFiller reads what a person or a browser would use to understand it:

Clue	Example
The autocomplete attribute	autocomplete="tel"
The input type and inputmode	type="email", inputmode="decimal"
The label and accessible name	<label>Téléphone</label>, aria-label, aria-labelledby
The name and id	name="contact_phone", id="userEmail"
The placeholder and title	placeholder="Company (optional)"
Text beside the field	a table cell or a <span> before it, when there's no label
The section it's in	a fieldset legend, a radio group's question
Units in the label	Longueur (mm), Poids (kg), Prix (€), (%)
The answers it offers	a list of countries, wilayas, genders or steel grades

Names generated by frameworks, such as field_7, mat-input-3 or :r5:, carry no meaning, so they're ignored.

All text goes through the same cleanup: case, accents, Arabic diacritics and letter variants, punctuation, and the ways developers write names. phone_number, phoneNumber, PHONE-NUMBER, phonenumber and numéro de téléphone all become the same clue.

2. Match the clues to field types

DevFiller knows 46 field types, each with its words in English, French and Arabic. A clue can match a type in several ways, and stronger matches count for more:

• The whole label: Email address is an email.
• A phrase inside a longer label: Your email address contains email address.
• A word inside a name: userEmail, contact_phone, billingcity.
• A plural or a typo: Comments, Emial, Frist name.

Common words such as "name", "date" or "title" only count on their own or alongside other clues, so "Project name" isn't mistaken for a person's name, and "Delivery date" is a date only when the field is a date input.

3. Score each candidate

Every clue adds weight to the types it points to. Clues that usually say the same thing, such as a label and its placeholder, count once; independent clues, such as a label and an autocomplete token, reinforce each other.

Some clues count against a type. A password box isn't an email, a number input isn't a city, a field that mentions "search" isn't a shipping address, and a label with a unit such as (mm) isn't a name.

When the two best types are close, as in "Email or phone", the field is ambiguous, and its confidence drops.

Confidence	What DevFiller does
90% and up, or 70–89%	Fills the field with that type's value
50–69%	Fills it only when Fill unknown fields is on, and says why otherwise
Below 50%	Treats the field as unknown: readable words when Fill unknown fields is on, or AI suggestions when AI is on

The side panel shows each field's type, its confidence and the clues behind it, for example "Phone, 96%: autocomplete=tel, label “Téléphone”". If DevFiller got a field wrong, choose the right type with This field is and it's used on that site from then on.

4. Read the form as a whole

After each field is scored on its own, DevFiller looks at the form around it:

• Confirmations. "Confirm", "Repeat your email" or "Retype it" repeats exactly the value of the field it confirms.
• Passwords. On a change-password form, the current password gets a different value from the new one.
• Dates. "Arrival" and "Departure", "From" and "To", "Du" and "Au", or "من" and "إلى" become a start and an end date, and the end always falls after the start.
• Choices. A select or radio group is recognized from its answers, and picks the one that matches the generated value: "Femme" or "أنثى" for a female identity, "16 - Alger" for Algiers.
• Split dates. Day, month and year selects under a "Date of birth" legend get the parts of one date.
• Payment sections. A name or an expiry date next to card fields belongs to the card, so it's skipped.
• "Please specify". A text field that completes the choice before it ("Grade — précisez") holds the same kind of value.
• The form's type. Sign-in, sign-up, checkout, booking, contact or search, shown in the side panel.

5. Never fill what must stay yours

Some fields are recognized so they can be skipped, whatever your settings:

• card numbers, expiry dates, CVV and cardholder names
• one-time, SMS and two-factor codes
• IBAN, BIC, RIB and bank account fields
• consent: terms, privacy, newsletters, marketing, permissions, data sharing and declarations such as "I certify that…", in English, French and Arabic
• session choices such as "Remember me" or "Keep me signed in"

The same rules apply to custom switches and checkboxes built by component libraries. DevFiller never submits a form.

6. Write a value that fits

A recognized field gets a value that fits the field, the form and the page:

• Consistent identities. The username and email follow the generated name.
• Places that agree. The city, district, postal code, state or wilaya, country and phone number come from one country. The Algeria profile uses real communes and dairas from the 69 wilayas of Law 26-06 of 2026.
• Numbers sized for their unit. A thickness in mm gets a few millimetres, a length in mm a few thousand, a weight in kg a decimal, with a decimal comma on French pages.
• Codes that look real. An order number becomes CMD-2030-0421, an invoice number FAC-… or INV-…, and a field that wants digits gets digits.
• Phones that follow the form. A dial code on the field, or the country chosen in the form, decides the phone format.
• Within the field's rules. Values respect min, max, step, maxlength and dates' ranges, and dropdowns and radio buttons get a real option.

Before writing a value, DevFiller checks it the way the browser would, against the field's pattern, type and length. If the field would reject it, DevFiller tries another way of writing the same thing: a national phone number, a day-first date, a code without dashes, the other decimal separator. After the fill, it waits a moment for the site's own validation, and if the site marks a field as invalid, it tries the next format.

Custom widgets built from ARIA roles, such as switches, radio groups, dropdowns that open a list, and rich-text editors, are filled the way a person uses them: pressed, opened, an option chosen, text typed.

With a seed in Repeatable data, all of this gives exactly the same values on every fill.

How accurate it is

DevFiller's accuracy is measured, not guessed. A benchmark fills labelled forms in real Chrome and checks every field: in English, French and Arabic, with misleading names, missing labels, typos, generated IDs, units and custom widgets. It fails on any sensitive field filled, any form submitted, any network request, and any drop in accuracy. Every reported problem becomes a test form before it's fixed.

The fairest numbers come from held-out forms the engine was never tuned on:

On forms DevFiller has never seen	Result
Fields given a type, and that type is right	about 96%
Fields that have a type, and DevFiller finds it	about 89%
Sensitive fields filled	none

The fields it misses become unknown, not wrong: with Fill unknown fields on they get readable text, and you can fix any of them with This field is or a custom field. Found a form DevFiller gets wrong? Click Export as test fixture in the side panel: it saves the form's structure, never the values in it, and you can attach it to an issue.