react-hook-form vs TanStack Form vs Formik: the 2026 Next.js comparison

Quick answer (September 2026). Pick react-hook-form for almost every new Next.js project: it ships zero runtime dependencies, it was published six days ago, and its issue tracker is genuinely empty. Pick TanStack Form when you need one form API across React and other frameworks, or when you want Standard Schema validation built into the core rather than bolted on. Do not start a new project on Formik in 2026. It still works and it is still the smallest single file of the three, but its repository has not been pushed to in 312 days, and the next tag that npm advertises for it resolves to a prerelease published in December 2020.

We checked all three against the live npm registry, the published tarballs and the GitHub API on 18 September 2026. Every number below is from that pass, not from a secondary article.

Why this comparison is different in 2026

React form libraries used to be compared on re-render counts. That argument is settled: all three avoid re-rendering the whole tree, and for the form sizes most SaaS apps actually build, the difference is not measurable by a user.

What separates them in 2026 is three things nobody puts in a benchmark: how the validation layer plugs in, what you inherit in your dependency tree, and whether the project is still being worked on. Those are all directly measurable, so that is what we measured.

The maintenance signal

Two of these three repositories were pushed to on the day we ran the check. The third was last pushed 312 days earlier, and its final push carries the same timestamp as its final npm publish, which is the signature of a release commit and then nothing.

The number that stands out is not Formik's 702. It is react-hook-form's 2 open issues against 44,862 stars. We double-checked that through the GitHub search API rather than trusting the summary count, because the repository endpoint folds pull requests into open_issues_count and would have reported 9. Two genuine open issues on a library at that scale is unusual enough that it is worth saying plainly: somebody is triaging that tracker aggressively.

TanStack Form's 120 open issues and 85 open pull requests are not a warning sign. That is a normal profile for a library in active pre-2.0 development with a large contributor surface.

The tag that has not moved since 2020

This is the finding we did not expect, and it is the single clearest reason not to start new work on Formik.

npm packages carry named distribution tags. Formik publishes three: latest points at 2.4.9, canary at a 2.1.6 prerelease, and next at 3.0.0-next.8.

That version was published on 2 December 2020. It is 2,116 days old, which is five years and nine months. Anyone who runs an install against the next tag today, reasonably expecting a preview of the upcoming major, gets a build from 2020.

The full 3.0.0 prerelease line tells the story on its own. All nine prereleases, next.0 through next.8, were published between 27 October and 2 December 2020. The v3 line started and stopped inside six weeks, and the tag pointing at it was never retired.

Compare that with the other two, which also have a next major in flight:

react-hook-form's v8 is worth a note of its own, because it looks abandoned until you read the dates properly. Its first four alphas landed in early 2022, then nothing for 1,266 days, then alpha.5 in October 2025 followed by four betas through July 2026. That is a restarted effort, not a stalled one.

What you actually install

Formik declares eight runtime dependencies: @types/hoist-non-react-statics, deepmerge, hoist-non-react-statics, lodash, lodash-es, react-fast-compare, tiny-warning and tslib. Note that it declares both lodash and lodash-es, which are the CommonJS and ES module builds of the same library. That is a deliberate dual-build choice so that both bundler paths resolve, but it does mean your lockfile carries both.

react-hook-form declares zero runtime dependencies. Its only peer is React.

TanStack Form declares two, @tanstack/form-core and @tanstack/react-store, and form-core in turn pulls @tanstack/store, @tanstack/pacer-lite and @tanstack/devtools-event-client. So the honest count is five packages in the tree, though they are all first-party TanStack modules rather than third-party transitive risk.

Bundle size, and the number that points the wrong way

Here is the result that cuts against the rest of this article, so we are putting it in its own section rather than burying it.

We gzipped the production builds straight out of the published tarballs:

Formik is the smallest of the three by roughly half. If bundle size were the only axis, the least maintained library would win it.

That figure needs one correction to be useful, and it is the reason we did not lead with it. It measures Formik's own dist file and nothing else, while Formik's eight runtime dependencies are exactly what is missing from it. react-hook-form's 14,318 bytes is the whole cost, because there is nothing else to add. Formik's 7,115 is a floor that lodash sits on top of, and how much of lodash survives depends on your bundler.

The TanStack figure is also an upper bound rather than a measurement of a real app. We summed both packages' ESM output, and a real build tree-shakes across them. Treat it as a ceiling.

The licence detail we found in the tarball

We read the licence from the published tarball rather than the registry metadata, because the registry's one-word license field cannot express a condition.

Formik's package declares Apache-2.0. Its published tarball contains 21 files, and none of them is a LICENSE or NOTICE file. react-hook-form and TanStack Form both ship package/LICENSE with the full MIT text.

The honest reading here is milder than it first looks, and worth stating carefully. The Apache-2.0 text is present in Formik's GitHub repository, on both the main and master branches, and we fetched it to confirm. So this is a packaging omission, not a project with no licence. What it means in practice is narrower: Apache-2.0 section 4 requires anyone redistributing the work to give recipients a copy of the licence and to retain the NOTICE file. If you vendor or redistribute Formik, that obligation is yours, and the text you need is not in the package you installed. You have to go and get it.

It is also worth noticing that Formik is the only one of the three that is not MIT. Apache-2.0 carries an express patent grant, which some legal teams prefer, alongside the attribution requirement above. For most product teams neither matters. For anyone shipping into an environment with a licence allowlist, it is the kind of thing that is much cheaper to know now.

Standard Schema is the real architectural split

The most consequential difference between these three in 2026 is not performance. It is where validation attaches.

Standard Schema is a small shared interface that validation libraries implement so that consumers can accept any of them without writing an adapter per library. Support here is genuinely split three ways.

TanStack Form has it in the core. We counted 67 references to the Standard Schema interface inside @tanstack/form-core's published files. You hand it a schema and it works, with no adapter package.

react-hook-form has it, one package over. Its core has zero references, which looks like absence until you look at the resolver package. @hookform/resolvers 5.9.1, published 17 August 2026, depends on @standard-schema/utils and declares peer support for 25 validators, including Zod, Valibot, ArkType, TypeBox, Yup, Joi, Vest, Effect and @standard-schema/spec itself. This is a design decision rather than a gap: validation stays out of the core bundle and you install only the adapter you use.

Formik has neither. Zero references in its published files. You wire validation through validate or validationSchema by hand, which is how it worked in 2019 and still works now.

If you are choosing a validator and a form library at the same time in 2026, this is the axis that will actually shape your code.

React 19 and the quiet peer range

All three install cleanly against React 19, but they say so in very different ways.

react-hook-form declares ^16.8.0 || ^17 || ^18 || ^19. TanStack Form declares ^17.0.0 || ^18.0.0 || ^19.0.0. Both are affirmative lists: somebody added React 19 to that range deliberately.

Formik declares an open-ended range of 16.8.0 or newer. That permits React 19 without anyone ever having asserted it works, because the range was written before React 19 existed and has not been touched since. The practical difference is not whether it installs. It is that the other two projects made a claim you can hold them to, and Formik's range simply never excluded anything.

Which one to pick

Start on react-hook-form unless you have a specific reason not to. Zero dependencies, a tracker with two open issues, a release six days ago, and the widest validator support in the ecosystem through its resolvers package. It is the boring correct answer for a Next.js app.

Start on TanStack Form if you want Standard Schema validation with no adapter layer, if you are sharing form logic across React and another framework, or if you are already invested in the TanStack ecosystem. Accept that you are on a 1.x with a 2.0 alpha moving underneath you.

Stay on Formik if you already have it in production and it is working. It is not broken, it did ship two releases in November 2025, and migrating a large form surface for its own sake is rarely worth it. Budget for the move rather than rushing it, and if you redistribute your build, go and collect that licence text.

Do not start on Formik in 2026. Not because any single measurement above is fatal, but because a dead next tag, 312 days of repository silence, 702 open issues and no Standard Schema support all point the same way, and the alternative costs you nothing.

How we measured this

Every figure here came from live sources on 18 September 2026: package metadata and publish timestamps from the npm registry API, dependency lists and licence files read out of the published tarballs with tar, gzipped sizes computed from those same tarball contents, and repository state from the GitHub REST and search APIs. Issue and pull request counts are split rather than combined, because GitHub's repository endpoint reports them as one number. Search volumes were not used to judge any library's quality.