Realistic HTML forms with labelled fields (tax, KYC, shipping, insurance, legal, finance) for exercising browser autofill and form-field detectors.
A downloadable, self-contained contact form — name, email, subject, and message with native HTML5 validation and a honeypot. Open it straight from disk; no scripts or requests leave the page.
A downloadable form exercising every common input type — text, email, tel, url, number, date, time, colour, range, select, radio, checkbox, file, and textarea — for testing autofill, scrapers, and parsers.
A downloadable account sign-up form with username/password constraints, a required terms checkbox, and native validation — a realistic registration form for testing form tooling.
A downloadable survey form with mixed question types — a rating scale, dropdown, checkbox and radio groups, a satisfaction slider, and a comment box.
A downloadable job-application form — contact details, position, experience, a résumé file input, cover letter, work-authorization radios, and a consent checkbox.
A downloadable login form — email and password with a remember-me toggle and native HTML5 validation, for testing autofill and credential-manager behaviour.
A downloadable mock-checkout form — shipping address plus a payment section that accepts the standard test card 4111 1111 1111 1111. Nothing is charged or stored.
A downloadable event booking / RSVP form — guest count, date and time, meal choice, dietary requirements, and notes.
A downloadable feedback form with a 0–10 Net Promoter Score scale, what-you-liked checkboxes, and a comment box.
A downloadable file-upload form — a required file input with an accept filter, an optional multiple-file input, and native validation. Nothing is uploaded off your device.
A downloadable sectioned registration form — personal details, account credentials, and address — with grouped fieldsets and native validation.
A downloadable international address form — two address lines, city, region/state, a postal-code pattern, and a country selector, for testing autofill and address parsers.
A downloadable newsletter-subscription form — email, interests, frequency, and a consent checkbox.
A downloadable appointment-scheduling form — service selection, a date and time picker, and contact details.
A downloadable password-reset request form — a single email field with native validation and a neutral, enumeration-safe success message.
Fictional US-style taxpayer info worksheet for testing tax-form autofill and parsers. Not an IRS form.
Know-your-customer style identity form with DOB, document type, and file upload — fictional SAMPLE IDs only.
Ship-from / ship-to, dimensions, HS code, and signature fields for logistics form testing.
Policy number, loss date, description, and photo upload for insurance-claim form tooling tests.
Parties, term, and signature fields for testing legal-form parsers. Sample contract text — not legal advice.
Checkbox consent + signature style medical acknowledgment for healthcare form testing. Fictional clinic.
Income, employment, and amount fields for credit-application form testing. Entirely fictional SAMPLE data.
Fictional US employment eligibility worksheet for I-9-style autofill tests. Not a USCIS form.
Fictional residential lease intake for property-management form parser tests.
Nonprofit donation/pledge form for fundraising CRM import tests.
Event RSVP form with guest count for calendar and seating workflow tests.
Fictional wire/ACH transfer request with SAMPLE routing numbers — not a real bank form.
K–12 student enrollment SAMPLE for SIS import and autofill tests.
Campus parking permit application with SAMPLE plate number.
Lease addendum SAMPLE for pet/policy amendment form tests.
Monthly recurring donation SAMPLE for nonprofit CRM tests.
Secondary vehicle registration fields for parking office tests.
Payroll direct deposit SAMPLE paired with employment forms.
Residential move-in inspection checklist SAMPLE.
A structured software bug report for testing issue intake, triage imports, severity mapping, and reproducible expected-versus-actual defect records. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the bug report HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the bug report family.
Fictional submitted values for every documented bug report field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional bug report response with columns in the same order as the field manifest.
An accessibility defect report for keyboard, assistive-technology, contrast, and semantic testing with enough context to reproduce the barrier. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the accessibility issue report HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the accessibility issue report family.
Fictional submitted values for every documented accessibility issue report field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional accessibility issue report response with columns in the same order as the field manifest.
A level-one to specialist support handoff for testing ticket escalation, impact classification, troubleshooting history, and callback-field imports. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the support escalation HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the support escalation family.
Fictional submitted values for every documented support escalation field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional support escalation response with columns in the same order as the field manifest.
A product-return authorization request for testing commerce intake, order and SKU matching, condition codes, quantities, and requested-resolution workflows. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the product return rma HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the product return rma family.
Fictional submitted values for every documented product return rma field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional product return rma response with columns in the same order as the field manifest.
An employee expense claim for testing finance-form parsing, currency and decimal handling, receipt references, policy categories, and approval exports. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the expense reimbursement HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the expense reimbursement family.
Fictional submitted values for every documented expense reimbursement field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional expense reimbursement response with columns in the same order as the field manifest.
A fictional supplier intake form for testing procurement imports, service categorization, contact normalization, data-access review, and compliance acknowledgements. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the vendor onboarding HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the vendor onboarding family.
Fictional submitted values for every documented vendor onboarding field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional vendor onboarding response with columns in the same order as the field manifest.
A nonprofit volunteer application for testing applicant imports, role choices, availability, contact autofill, free-text skills, and consent handling. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the volunteer application HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the volunteer application family.
Fictional submitted values for every documented volunteer application field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional volunteer application response with columns in the same order as the field manifest.
A service estimate request for testing lead intake, scope extraction, site classification, schedule normalization, budget bands, and contact-field mapping. This standalone HTML reference works offline, uses explicit labels and native validation, and submits nowhere.
A one-page fillable PDF twin of the service quote request HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
Machine-readable field names, labels, types, required states, choices, and input hints for the service quote request family.
Fictional submitted values for every documented service quote request field, suitable for request parsing, mapping, and round-trip tests.
A one-row UTF-8 CSV export of the fictional service quote request response with columns in the same order as the field manifest.
Minimal SAMPLE HTML form (contact-mini) for autofill and form-parser tests.
Minimal SAMPLE HTML form (newsletter-mini) for autofill and form-parser tests.
Minimal SAMPLE HTML form (login-mini) for autofill and form-parser tests.
Minimal SAMPLE HTML form (search-mini) for autofill and form-parser tests.
Minimal SAMPLE HTML form (feedback-mini) for autofill and form-parser tests.
Minimal SAMPLE HTML form (rsvp-mini) for autofill and form-parser tests.
Minimal SAMPLE HTML form (upload-mini) for autofill and form-parser tests.
A form that pairs each HTML control kind with a mandatory and an optional twin, so a validation harness can prove it detects the required attribute on text, email, number, date, select, textarea, radio group and consent checkbox alike.
Eight text controls carrying anchored pattern regexes - postcode, SKU, hex colour, slug, IPv4, ISO week, licence key and username - each with a title that supplies the message browsers otherwise phrase generically.
Bounded numeric and temporal controls: integer and decimal steps, a slider with a live readout, a fractional currency step, and date, month and time inputs whose min, max and step define exactly which values are valid.
Textual controls carrying explicit minlength and maxlength bounds - including the exact-length and maximum-only cases, and a textarea whose counter hint and attribute must agree - for testing length validation and truncation behaviour.
Controls stacking required, pattern, length and range rules at the same time, including two deliberately awkward cases - a pattern narrower than its length bound, and a step that cannot reach the maximum - for testing which constraint a validator reports first.
A counterpart to the rest of the catalog's forms: it omits novalidate, so the browser's own constraint UI blocks submission and shows the bubble. Use it to tell native enforcement apart from script-driven validation in the same harness.
Editable, read-only and disabled variants of the same controls side by side. Read-only values are submitted and disabled values are not, which is the distinction form scrapers and autofill tools most often get wrong.
The six textual HTML input types on a single page, each with the autocomplete token and validation attributes it normally carries, so a parser can be checked type by type rather than against a mixed realistic form.
Number and range controls covering integers, decimals, negative bounds and a slider paired with a live output element, for testing numeric coercion, locale-independent parsing and slider readout scraping.
All five temporal HTML input types with explicit bounds and sample values, including the two that many form libraries silently downgrade to plain text - month and week - so a round trip can be verified format by format.
Every way HTML expresses a choice: a single select with a prompt row, a multiple select, a select with option groups, a radio group, a checkbox group and a lone checkbox - including options whose submitted value differs from their visible label.
The input types that behave unlike the rest: a colour picker, a file control, two hidden state fields that carry values without a visible control, and a textarea whose newlines are submitted data rather than layout.
A form whose button-shaped inputs outnumber its data fields. Submit, reset, plain button and image controls are named and typed like fields but must never appear in an extracted field list, which is a common form-scraper defect.
Page one of a three-file sign-up wizard. Each page validates only its own fields and hands the wizard identifier forward in a hidden control, which is the pattern multi-page form automation has to follow.
Page two of the sign-up wizard. It repeats the wizard identifier, advances the step counter and collects profile fields, so a driver can be tested on resuming a flow it did not start.
Page three of the sign-up wizard. It echoes the earlier answers into read-only controls that are still submitted, so a driver can be tested on the difference between a summary rendered as text and one rendered as form state.
A single page whose visible questions depend on the request type chosen. Three mutually exclusive blocks are present in the markup at all times, so the same file exercises both an automation that reads the DOM and one that only sees what is on screen.
A form where a script adds and removes the mandatory flag at runtime. The attribute is absent from the shipped markup on purpose, so a validator that reads the file statically and one that reads the live DOM give different answers.
A country list that rewrites a region list in the browser. The regions live in a script rather than the markup, so a scraper that reads the shipped HTML sees an empty second list and one that drives a real browser sees four options.
Two text controls placed outside the form element and associated with it through the form attribute. A scraper that walks only the form subtree misses them, which is exactly the defect this file exists to surface.
The identity half of the autofill vocabulary: honorific prefix and suffix, given, additional and family name, nickname, organisation, job title, birthday parts, sex and language. Each token appears once, on the control type the specification names for it.
A complete shipping address using the shipping-prefixed autofill tokens, including the street-address textarea and the three address-line controls that many autofill engines treat differently from one another.
The billing-prefixed twin of the shipping address form, deliberately using the same visible wording so an autofill engine has to distinguish the two sections by their token prefix rather than by label text.
The payment autofill tokens - cc-name, cc-given-name, cc-family-name, cc-number, cc-exp and its parts, cc-csc and cc-type - on a form that has no action, no script and no prefilled values. It exists to exercise token recognition, never to take a payment.
The contact channel tokens - the five telephone parts, email, impp, url and photo - plus the one-time-code token that lets a browser or password manager offer a verification code. Includes the webauthn hint on the code control.
Four file controls whose accept expressions narrow the picker in different ways: a wildcard media type, an explicit list of media types, an extension list, and a capture hint that asks a phone for the camera rather than the gallery.
Document accept lists including the verbose OpenXML media types that are the usual source of accept-attribute mistakes, plus a control that pairs a media type with the matching extension so both matching strategies succeed.
Multi-file controls with the limits an application would enforce on the server stated in help text and data attributes. HTML has no size or count constraint, so this file is the reference case for a validator that has to apply those rules itself.
A form that mixes text, a checkbox group and two file controls under multipart form-data encoding. Paired with the raw multipart body shipped alongside it, so a parser can be checked against both the form and a request it would produce.
A drop surface that lists filenames in the browser, layered over a real file input so keyboard and assistive-technology users reach the same control. Useful for testing automation that has to choose between synthesising a drop event and setting the input directly.
A booking form that separates the date from the slot, so a scheduler has to read a bounded date control and a radio list of times rather than a single free-text field. Includes an accessibility need and a reminder channel.
A passphrase form where the written policy and the enforced pattern match exactly, plus a confirmation control and a strength meter. Most fixtures state rules they do not enforce, so this one is the reference for testing that agreement.
A second-factor enrolment flow covering the three common methods and the six-digit confirmation control that carries the one-time-code autofill token. No code is generated and nothing is verified.
The screen an address verifier shows after standardising an entry: the original and the suggestion side by side as a radio choice, plus editable fields prefilled with the standardised form.
A purchase order with repeating line items whose field names use array notation, so a parser has to reconstruct three rows from flat form data. The total is computed in the browser and submitted as a read-only control.
A warranty registration covering the fields that make post-purchase records awkward: a serial number with a checksum-shaped pattern, a purchase date bounded to the past, and a retailer list with an other option.
A preference centre with six topic checkboxes, a frequency radio group and a master unsubscribe control that must override every other choice. The override interaction is the behaviour worth testing here.
Four radio groups - severity, likelihood, blast radius and confidence - that a triage rule combines into a priority. The groups share nothing but their layout, which makes it a good test of group-name resolution in a dense form.
A five-by-five Likert matrix: five statements, each a radio group over the same five points. Twenty-five radio controls that resolve to five fields is the densest grouping case in the catalog.
Consent expressed as separate, unticked controls for each purpose, with an undeletable line saying the form is fictional. The point of the fixture is that no control is pre-ticked and none of them is bundled with another.
A monitoring section where every question is optional and every list ends with a prefer-not-to-say option, which is the design most such forms get wrong. No answer is mandatory and the form states that it is separated from the application.
A leave request where the second date must not precede the first and the working-day count is computed in the browser. The cross-field date rule is the constraint HTML cannot express, which makes it a useful validator fixture.
An equipment loan slip covering the asset tag, collection and return dates, a condition declaration and an accessory checklist, which together exercise pattern, date and checkbox-group parsing in one realistic document.
Sixty named controls across ten titled sections. Large enough to expose pagination, truncation and quadratic behaviour in form extractors, and regular enough that a failure is easy to localise.
Control names and labels outside ASCII, including a combining-accent pair that is visually identical to a precomposed one. A form parser that normalises names, or that assumes ASCII, produces a different key set from one that does not.
A right-to-left document whose controls mix Arabic labels with Latin and numeric values, including one control forced back to left-to-right. Useful for testing bidirectional layout, direction inheritance and value extraction order.
Labels and default values made of characters that have to be escaped in HTML - ampersands, angle brackets, both quote marks and a non-breaking space. A parser that decodes entities once too often or not at all produces visibly wrong text here.
Control names in bracket notation - customer[name], customer[address][city], items[0][sku] - that many server frameworks explode into nested objects. The file is the reference case for a parser that has to rebuild the graph from flat name and value pairs.
Controls that share a name on purpose: three tags[] text inputs, a multiple select and a checkbox group all submit repeated keys. This is valid form data, unlike the intentionally corrupt duplicate-name fixture shipped alongside it.
Intentionally corrupt. Three pairs of unrelated controls share a name - two email inputs, two dates and a select that collides with a text input - so the submitted body carries the same key twice with different meanings. Use it to check that a parser reports the collision instead of silently keeping the last value.
Intentionally corrupt. A second form element opens inside the first, which HTML forbids. Browsers drop the inner tag and attach its controls to the outer form, while many static parsers report two forms - so the same file yields a different field list depending on who reads it.
Intentionally corrupt. A select has two options with the same value under different labels, a radio group repeats a value, and one option's value contradicts its wording outright. A form that reads labels and a form that reads values disagree about what was chosen.
Six independent AcroForm checkboxes covering both tick states and four button styles. This HTML twin carries the same canonical field names as the AcroForm PDF of the same name, so a filler can be tested against both representations of one form.
One AcroForm radio field whose four kids share a parent, plus a second three-kid group. This HTML twin carries the same canonical field names as the AcroForm PDF of the same name, so a filler can be tested against both representations of one form.
Two AcroForm choice fields, one plain drop-down and one editable combo box. This HTML twin carries the same canonical field names as the AcroForm PDF of the same name, so a filler can be tested against both representations of one form.
AcroForm list boxes, including one that permits several selections at once. This HTML twin carries the same canonical field names as the AcroForm PDF of the same name, so a filler can be tested against both representations of one form.
A signature block drawn as a ruled area with named text fields - not a digital signature field. This HTML twin carries the same canonical field names as the AcroForm PDF of the same name, so a filler can be tested against both representations of one form.
Text fields carrying the comb, multiline, password and read-only AcroForm flags. This HTML twin carries the same canonical field names as the AcroForm PDF of the same name, so a filler can be tested against both representations of one form.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
