Every form artifact in the library opens here: edit layout-backed HTML forms, inspect honest PDF layouts, or edit JSON, CSV, TXT, FDF, and XFDF values in their original format. Drafts stay in your browser, and no account is needed. Signed in, you can also save a form’s fields and layout to your account; files and filled-in values never leave your browser.
153 real fixtures from the library. Layout definitions stay tied to their downloadable source; field-value containers keep their native escaping and companion-PDF context. Sample markings on legal, financial, and healthcare templates remain protected.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Six independent AcroForm checkboxes covering both tick states and four button styles. A one-page fillable AcroForm whose canonical field names match the HTML twin, the FDF and the XFDF of the same name, so one form can be tested across four representations.
Two AcroForm choice fields, one plain drop-down and one editable combo box. A one-page fillable AcroForm whose canonical field names match the HTML twin, the FDF and the XFDF of the same name, so one form can be tested across four representations.
AcroForm list boxes, including one that permits several selections at once. A one-page fillable AcroForm whose canonical field names match the HTML twin, the FDF and the XFDF of the same name, so one form can be tested across four representations.
One AcroForm radio field whose four kids share a parent, plus a second three-kid group. A one-page fillable AcroForm whose canonical field names match the HTML twin, the FDF and the XFDF of the same name, so one form can be tested across four representations.
A signature block drawn as a ruled area with named text fields - not a digital signature field. A one-page fillable AcroForm whose canonical field names match the HTML twin, the FDF and the XFDF of the same name, so one form can be tested across four representations.
Text fields carrying the comb, multiline, password and read-only AcroForm flags. A one-page fillable AcroForm whose canonical field names match the HTML twin, the FDF and the XFDF of the same name, so one form can be tested across four representations.
A fillable PDF job-application AcroForm: text fields, a position dropdown, work-authorization radio buttons, a relocate checkbox, a multiline cover letter, and a signature block. Fill it in any PDF viewer; no macros or scripts.
A fillable PDF patient-intake AcroForm: demographics, sex radios, reason-for-visit, allergies, medications, and a consent checkbox. A sample layout only. Never enter real medical data.
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.
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 form captured after a failed submission: three controls carry aria-invalid with an aria-errormessage pointing at their message, and a summary region links to each one. Use it to test error announcement and focus management without having to trigger a failure first.
One control per inputmode token - none, text, decimal, numeric, tel, search, email and url - each paired with the input type it realistically accompanies, for testing mobile keyboard selection and hint propagation.
Every control carries both a name and a description, wired with aria-describedby to the hint that explains its rule. Use it to check that a scanner reports the description as well as the name, and does not merge the two.
No label element appears anywhere. Each control points at a span through aria-labelledby, including one control whose name is assembled from two references, which is the case that catches naive accessible-name implementations.
The reference labelling technique: each control carries an id and is named by a separate label element pointing at it. Use it as the known-good baseline when comparing accessible-name computation across the other labelling fixtures in this set.
A deliberate anti-pattern. No control has a label element, an aria-label or an aria-labelledby, so every accessible name has to be guessed from the placeholder or the name attribute. Ship it as a failing case for an accessibility scanner, never as a template to copy.
Every control has a real label element that is clipped out of view, while the visible wording lives in a placeholder. A visual scraper and an accessibility tree walker see different text for the same control, which is the point of the file.
Implicit labelling: each control is a child of the label that names it and no for attribute is present. Parsers that resolve names only through for and id will report six unnamed controls on this file.
Fieldsets nested three levels deep, each carrying a legend, so a grouping algorithm has to compose several group names rather than take the nearest one. Includes a radio group nested inside a titled section.
Intentionally corrupt. Every label carries a for attribute naming an element that is not in the document, and two controls share one id, so no control has a computed accessible name from its label. An accessibility scanner should report five unnamed controls and one duplicate id.
An adjustment request built around what somebody needs rather than why, so it collects no health information at all. Useful as an accessible-form reference and as a counter-example to intake forms that ask for a diagnosis.
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.
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 downloadable login form: email and password with a remember-me toggle and native HTML5 validation, for testing autofill and credential-manager behaviour.
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 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 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.
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 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 downloadable job-application form: contact details, position, experience, a résumé file input, cover letter, work-authorization radios, and a consent checkbox.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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 one-page fillable PDF twin of the volunteer application HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
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.
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 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.
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.
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.
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.
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.
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.
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 one-page fillable PDF twin of the vendor onboarding HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
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 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 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 one-page fillable PDF twin of the support escalation HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
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 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.
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 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.
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.
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.
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.
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 service quote request HTML form. Its canonical AcroForm field tree, widgets, values, and appearance streams are generator-validated.
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.