Standalone documents, email markup, forms, malformed edge cases, and semantic page structures for testing HTML parsers, extractors, sanitizers, and DOM-import pipelines.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.
An EPUB 3 with a block MathML equation and the required properties="mathml" on its content document. The baseline for MathML support, paired with a twin that omits the declaration.
An EPUB 3 whose first spine item is an SVG content document rather than XHTML, followed by a chapter that explains what should have appeared. For testing readers that assume every reading-order document is XHTML.
SVG written straight into an XHTML content document, with properties="svg" declared on the manifest item as EPUB 3 requires. The other half of the SVG question: inline vector markup rather than a standalone content document.
A fixed-layout cover built as an SVG content document that pulls in a PNG through xlink:href and centres it as a single-page spread. For testing cover extraction, which usually looks for a raster and finds vector markup instead.
An EPUB 3 whose one content document declares properties="scripted" and contains a single inline script that rewrites one paragraph. It makes no network request and reads correctly with scripting switched off, so it tests the property and the fallback rather than the script.
The baseline every canonical audit should pass: one self-referential canonical, an indexable robots meta, matching hreflang self-reference and an og:url that agrees with all of them. For use as the comparison reference against the conflicting pages in this set.
Page A of a deliberately invalid two-page canonical loop: A declares B canonical while B declares A canonical, so no page in the pair is its own canonical. For testing that a crawler detects the cycle instead of following it forever.
Page B of the deliberately invalid canonical loop, closing the cycle by naming page A as its canonical. Ships with page A so the loop can actually be traversed rather than described.
A deliberately invalid page carrying two canonical tags in the head and a third in the body. Search engines ignore body-level canonicals entirely and treat multiple head-level ones as a conflict. For testing that an extractor reports position as well as value.
A page that names itself canonical while telling robots not to index it, and then contradicts that again with an agent-specific googlebot meta that permits indexing. For testing directive precedence when a page argues with itself.
The English member of a correct three-locale hreflang cluster: it lists itself, both translations and the x-default, and its canonical agrees. Ships with the German page so reciprocity can be verified across real files.
The German member of the same cluster, with lang="de" on the html element and the identical alternate block. For testing that an audit compares the annotation set rather than the document language, and that the two agree.
A deliberately invalid annotation block: `en-UK` is not a region code, `de_DE` uses an underscore, `zz` is not a language, one alternate has no hreflang attribute at all, one drops to http, there is no x-default, and the canonical points outside the cluster. For testing that every defect is reported, not just the first.
The HTML half of bidi handling: paragraphs with dir=ltr, dir=rtl and dir=auto, the same user-supplied string with and without a <bdi> wrapper, one balanced <bdo> showing display override scoped to a single element, and explicit RLM/FSI marks inside markup. No scripts and no external resources.
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.
