Best form blocks 2026: 32 verified sections

A form block is judged by what happens when the submit fails, not by its grid. The catalogue holds 32 form sections from 4 registries, measured on 1 November 2026, and the table below sorts them by file count rather than by looks.

Every failure comes from state. A button that stays active during the request creates two identical records; an error message printed at the top of the page is never announced by the screen reader; browser autofill writes into the input before React hydrates the component, and the field empties on first render. No static preview shows these, because each one needs a slow submit and a browser with a saved password.

Where a form breaks

The critical sequence never changes: focus on a field, error, correction, second submit. If the error is not tied to the field by an id, keyboard users restart from the top of the document. If focus stays on the button after the error, the message exists but is never read. If the form disables the button without a reason, the visitor assumes the site is frozen and reloads the page, losing everything typed.

The real cost: 84 npm packages

The 32 blocks add up to 39 files, 84 npm dependencies and 134 registry dependencies: 2.6 packages per block, the highest figure among the block categories in the catalogue. A block such as “React Hook Form + Zod” brings four packages, react-hook-form, zod, @hookform/resolvers and sonner, and all four land in every page that imports the form. Registry dependencies weigh the same: a block asking for field, input-group, checkbox and button drags half a design system with it.

• State library: react-hook-form and TanStack Form do not coexist well in one project, so pick one.
• Schema: when the block imports zod, client validation is already written and must be repeated on the server.
• Registry dependencies: the shadcn components the manifest requires, which can overwrite a version you already customised.
• Sample data: a “Payment form” block ships fake card numbers that must go before the deploy.

The table, sorted by files

The two rows called “Form in a Dialog” are the same recipe written for two different libraries: same interface, different state handling. It is the one place where the table offers a direct comparison, and it beats ten screenshots, because it tells you how much code changes when you swap the library without touching the design.

The five-minute test

Open the preview, submit the empty form, then submit a malformed email, then throttle to Slow 3G and double-click the button. Those three steps find most real defects: validation that never starts, an error nobody announces, a duplicate submit. Add a fourth check with the keyboard: from the first field to the last without a mouse, then Shift+Tab backwards.

• The button shows a pending state and refuses a second submit.
• Every error message is bound to its field through aria-describedby and a stable id.
• A field filled by autofill keeps its value after hydration.
• The block sample data is replaced or clearly marked as fake.

curl "https://ui.eneawork.it/api/blocks/category/form?limit=10"

A limit the count hides

Twenty-five blocks out of 32 come from a single publisher, flx, so design variety is far smaller than the number. Two rows, “Login form” and “Payment form”, are cards with a form inside rather than form sections, and a third is a checkbox with a schema. The catalogue says 32 because it counts sections that contain a form, not 32 different readings of the problem.

Decision rule

If the form goes past six fields or needs server validation, take the minimal recipe, fields, checkbox, messages, and own the state in your code: a large block imposes its structure and its library. Under three fields, a card block with the form inside is fine and saves a day. The alternative is a native form with a server action: no library, validation on the server, and the browser handles autofill, history and messages by itself. You lose instant validation and per-field messages, you gain a lighter bundle and predictable behaviour.

The sections live under /blocks/category/form, the inventory under /blocks, and the Zod recipe has its page here. For wiring schema to fields read react-hook-form with zod, for announced errors aria-live in forms, and for the library comparison the measured React form libraries.