Semantic pages, tables, forms, feeds, metadata, and downloadable fixtures for testing extraction and browser automation against stable, purpose-built targets.
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.
A complete urlencoded request dump with repeated keys, bracket notation, an encoded newline and a non-ASCII key, annotated with what each one tests. The host is example.invalid and nothing was ever sent.
A complete multipart request dump for the multipart upload form: two file parts with placeholder payloads, a filename containing a space and parentheses, a repeated field name and the empty honeypot.
A six-part review checklist for forms, with every line pointing at the fixture in this catalog that demonstrates it passing or failing. Fictional product; not legal advice.
Text and HTML alternatives that state different totals and different delivery dates. The spec says the parts must be alternative renderings of the same content, so this fixture shows what a tool extracts when they are not — the answer depends entirely on which part it picks.
A robots.txt built entirely from pattern rules: `*` inside a path, `$` anchoring the end of a URL, a query-string pattern, and an Allow that carves one file out of a disallowed subtree. For testing that a robots parser implements RFC 9309 path matching rather than prefix comparison.
A robots.txt where Googlebot is named by two separate groups and every Disallow has an equal-length Allow competing with it. For testing group merging, case-insensitive product tokens, and the rule that the most specific match wins with Allow breaking ties.
A robots.txt carrying three different crawl-rate hints - an integer Crawl-delay, a fractional one alongside Request-rate and Visit-time, and a very large one - none of which are part of RFC 9309. For testing that a crawler reads or ignores rate hints without dropping the Disallow rules that share the group.
A robots.txt declaring five sitemaps - before the first group, inside two different groups, in lower case, gzipped, and on another host. For testing that a discovery crawler collects Sitemap as a file-global field instead of scoping it to the group it sits in.
A robots.txt that disallows the entire site for every crawler while allowing one media path for a single image agent. For testing full-block handling and the common misconception that a Disallow removes a URL from a search index.
A robots.txt in which real Disallow rules are surrounded by Noindex, Host, Clean-param, Nofollow and two invented fields, several with inline comments. For testing that a parser skips fields it does not implement instead of aborting or mis-binding the rules that follow.
A robots.txt that begins with a UTF-8 byte-order mark, uses CRLF line endings, and leaves trailing spaces after two rule values. For testing the byte-level tolerances RFC 9309 requires - a leading BOM must be discarded rather than glued onto the first field name.
A robots.txt using upper-case, mixed-case and indented field names, a tab-indented rule, a value with no space after the colon, and both trailing and full-line comments. For testing that field names are treated case-insensitively while path values stay case-sensitive.
A deliberately invalid robots.txt: a rule before any group, an empty product token, an absolute URL where a path belongs, whitespace before the colon, a non-numeric Crawl-delay, and a line with no colon at all. For testing that a parser degrades line-by-line instead of failing the whole file.
The single most common broken robots.txt in the wild: a server that answers /robots.txt with its HTML 404 page instead of a 404 status. For testing that a crawler treats unparseable markup as 'no robots.txt' and allows the site rather than inventing rules from tag names.
A sitemap index listing three child sitemaps, one dated with a plain date, one with a full W3C datetime, and one with no lastmod at all. Two of the children ship alongside it, so a crawler can be walked from index to URL.
The first child of the sitemap index: six core URLs with a deliberately uneven mix of lastmod, changefreq and priority, including one entry that carries nothing but a loc. For testing that optional sitemap fields really are optional.
The second child of the sitemap index: six URLs dated with W3C datetimes in two different timezone offsets, including a changefreq of never and a priority of 0.1. For testing datetime normalisation and priority ordering.
A sitemap whose three URLs form a complete hreflang cluster: every page lists every locale including itself and a shared x-default. This is the shape an international audit should pass, and the reference twin of the broken cluster.
A deliberately invalid hreflang cluster: an `en-UK` region that does not exist, an underscore locale, a German page that never links back, a Spanish self-reference dropped to http, and no x-default anywhere. For testing that an international audit reports each defect rather than the first one.
A sitemap using the image extension namespace: six images across three pages, with and without titles and captions, in JPEG, WebP and AVIF. For testing extension-namespace parsing and image-discovery pipelines.
A sitemap using the video extension namespace: one fully populated entry with duration, rating, view count, country restriction and tags, and one minimal entry with only the required children plus a player attribute. For testing video-sitemap parsers and their attribute handling.
A two-URL news sitemap with publication name, language, publication date and headline for an English and a German article. For testing nested extension elements and per-article language handling.
A sitemap of URLs that need both layers of escaping the format demands: ampersands written as XML entities and reserved characters percent-encoded, plus a punycode host. For testing that a parser unescapes exactly once and does not double-decode.
The plain-text sitemap format the sitemaps.org protocol also accepts: one absolute URL per line, no markup, UTF-8 encoded. For testing that a crawler supports the text form as well as XML.
A 500-URL sitemap served the way large sites serve them - gzip-compressed as sitemap-large.xml.gz. The gzip header carries mtime 0 and no embedded filename, so the bytes are stable across regenerations. For testing that a crawler decompresses .xml.gz sitemaps before parsing.
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.
