# React Hook Form vs. Formik vs. TanStack Form thorough comparison [2026 latest] — selection criteria and migration guide

> How to choose a React form library in 2026. A fair comparison of React Hook Form, Formik, and TanStack Form on the axes of re-render strategy, bundle size, TypeScript inference, validation (Standard Schema), maintenance status, and learning curve. With real code, it explains the recommendation for new projects, the conditions where TanStack Form fits, and the step-by-step migration procedure from Formik.

- Published: 2026-06-26
- Author: 友田 陽大
- Tags: React, React Hook Form, TypeScript, 状態管理, Next.js, フォーム, 型安全, フロントエンド
- URL: https://tomodahinata.com/en/blog/react-hook-form-vs-formik-vs-tanstack-form-comparison-guide
- Category: React forms
- Pillar guide: https://tomodahinata.com/en/blog/react-hook-form

## Key points

- The default for a new React project in 2026 is React Hook Form — minimal-class bundle, the best TS inference, and a thick ecosystem (Zod/shadcn).
- TanStack Form is headless and cross-framework (React/Vue/Angular/Solid/Lit); it's a strong contender if type strictness or TanStack unification is a requirement.
- Formik is not recommended for new adoption. Maintenance is sluggish, and its control-centric design creates re-render problems in forms with 20+ fields.
- The core of the difference is the re-render strategy (RHF = uncontrolled, Formik = controlled, TanStack = per-field subscription).
- From Formik to RHF you can migrate per form, in stages, not all at once — the two can coexist.

---

"In 2026, what should you build React forms with?" — I answer this question not with position talk but with **the facts of design.** This article organizes the selection criteria and migration procedure with each library's official documentation ([React Hook Form](/blog/react-hook-form), [TanStack Form](https://tanstack.com/form/latest), [Formik](https://formik.org/)) and the latest comparisons as primary sources.

> **Conclusion (up front):** the **default for a new React project is React Hook Form.** **TanStack Form** is a strong rival if cross-framework or type strictness is a requirement. **Formik** works as an existing asset, but **new adoption is not recommended** (sluggish maintenance, the re-render cost of being control-centric). Below, I state the basis.

---

## 1. The difference in design philosophy — this is the fork for everything

The three libraries fundamentally differ in "how they hold form state."

- **React Hook Form (uncontrolled):** holds input values with `ref` and doesn't re-render during typing. Speed and brevity are its strengths.
- **Formik (controlled):** every input is controlled by React state. Easy to write, but the form re-renders on each keystroke, becoming heavy as the field count grows.
- **TanStack Form (per-field subscription):** headless, where each field subscribes to its own state. Framework-independent (React/Vue/Angular/Solid/Lit) and strict on types.

The meaning of "controlled vs. uncontrolled" is detailed in the [complete React Hook Form guide](/blog/react-hook-form). **This single point ripples into all of the performance, types, and learning curve described below.**

---

## 2. Comparison table (as of June 2026)

| Aspect | React Hook Form | Formik | TanStack Form |
| --- | --- | --- | --- |
| State model | uncontrolled (ref-centric) | controlled (React state) | per-field subscription (headless) |
| Re-render | minimal (almost none during typing) | many (the whole on each keystroke) | small (per field) |
| Bundle size | minimal-class | effectively largish (incl. deps) | lightweight (headless) |
| TypeScript inference | very strong | ordinary | very strong (type-driven) |
| Validation | via resolver (Zod, etc.) + Standard Schema | Yup-centric (many assets) | Standard Schema directly (Zod/Valibot) |
| Supported frameworks | React/React Native | React | React/Vue/Angular/Solid/Lit |
| Maintenance | active | sluggish (maintenance mode) | active (v1 stable) |
| Ecosystem | thick (shadcn/resolvers/RN) | shrinking | growing |
| Learning curve | a bit peculiar (understanding uncontrolled) | easy | a bit high (types/API) |

> **Note:** the figures move with the period. This table shows "relative tendencies"; confirm the latest accurate figures on each official site, bundlephobia, etc. The essence is **the difference in design**, more than the figures.

---

## 3. Situations where the difference in re-render strategy bites

This is the point where the practical difference shows most.

- **Small forms (a few fields):** almost no perceptible difference. Any of them is fine.
- **Large forms (20+ fields, line items, wizards):** Formik re-renders the whole on each keystroke and tends to lag. RHF is uncontrolled and re-renders almost none during typing. TanStack confines re-renders to the field level.

In other words, **"the heavier the form, the stronger the motive to move away from Formik."** RHF and TanStack both have designs that curb re-renders, and they're even here. For RHF optimization techniques, see the [performance optimization guide](/blog/react-hook-form-performance-rerender-optimization-guide).

---

## 4. Type safety and validation (the Standard Schema era)

An important trend of 2026 is **Standard Schema** — Zod, Valibot, ArkType, and others implement a common interface, so the library side is no longer tied to a specific validation library.

- **RHF:** `@hookform/resolvers` v5 supports Zod 4, Valibot, ArkType, and Standard Schema. Type inference is very natural in combination with Zod.
- **TanStack Form:** designed to receive Standard Schema as **first-class.** You can pass a schema directly to `validators`.
- **Formik:** assets premised on Yup are thick. You can connect Zod via `toFormikValidationSchema`, etc., but TS inference isn't as smooth as RHF/TanStack.

For validation-schema design itself, see the [Zod 4 practical guide](/blog/zod).

---

## 5. Situations to choose each (decision guide)

**Choose React Hook Form (default):**

- A new React / Next.js project.
- You want to ride the Zod + shadcn/ui ecosystem.
- You want a minimal bundle, the best TS inference, and the largest track record and information volume.

**Choose TanStack Form:**

- You want to reuse **the same form logic** outside React too (Vue/Solid/Angular/Lit).
- You've already adopted TanStack Query / Router and want to unify the philosophy.
- You most value type strictness and the freedom of headless.

**Choose Formik:**

- In principle, "**don't choose it for new work.**"
- Keep it only if you have existing Formik forms and can't migrate right now. Write new forms with RHF and migrate in stages.

---

## 6. Minimal code for the three (laid out fairly)

### React Hook Form

```tsx
const { register, handleSubmit, formState: { errors } } = useForm({
  resolver: zodResolver(schema),
});
return (
  <form onSubmit={handleSubmit(onSubmit)} noValidate>
    <input {...register("email")} aria-invalid={!!errors.email} />
    {errors.email && <p role="alert">{errors.email.message}</p>}
  </form>
);
```

### TanStack Form

```tsx
const form = useForm({
  defaultValues: { email: "" },
  validators: { onChange: schema }, // Standard Schema (Zod) を直接
  onSubmit: async ({ value }) => onSubmit(value),
});
return (
  <form onSubmit={(e) => { e.preventDefault(); form.handleSubmit(); }}>
    <form.Field
      name="email"
      children={(field) => (
        <input
          value={field.state.value}
          onBlur={field.handleBlur}
          onChange={(e) => field.handleChange(e.target.value)}
          aria-invalid={field.state.meta.errors.length > 0}
        />
      )}
    />
  </form>
);
```

### Formik

```tsx
<Formik initialValues={{ email: "" }} validationSchema={yupSchema} onSubmit={onSubmit}>
  <Form>
    <Field name="email" />
    <ErrorMessage name="email" component="p" role="alert" />
  </Form>
</Formik>
```

All three can be written, but **RHF is the shortest with `{...register}` because it's uncontrolled**, TanStack is **explicit per field** (high freedom but somewhat more boilerplate), and Formik is **straightforward because it's controlled, but contains the re-render cost.**

---

## 7. Formik → React Hook Form migration guide

**The big principle: don't migrate all at once.** The two can coexist in the same app. It's safe to migrate **per form, in the order you touch them** (Boy Scout Rule).

### Concept correspondence table

| Formik | React Hook Form |
| --- | --- |
| `initialValues` | `useForm({ defaultValues })` |
| `validationSchema` (Yup) | `useForm({ resolver: zodResolver(schema) })` |
| `handleChange` / `handleBlur` | contained in `register("name")` |
| `values` | `watch` / `useWatch` / `getValues` |
| `errors` / `touched` | `formState.errors` / `formState.touchedFields` |
| `isSubmitting` | `formState.isSubmitting` |
| `setFieldValue` | `setValue` |
| `setFieldError` | `setError` |
| `FieldArray` | `useFieldArray` |
| `<Field>` / `<ErrorMessage>` | `register` + your own error display (or shadcn's `FormField`) |

### Before (Formik)

```tsx
<Formik
  initialValues={{ email: "", name: "" }}
  validationSchema={Yup.object({ email: Yup.string().email().required() })}
  onSubmit={async (values, { setSubmitting }) => {
    await api.save(values);
    setSubmitting(false);
  }}
>
  {({ isSubmitting }) => (
    <Form>
      <Field name="email" type="email" />
      <ErrorMessage name="email" />
      <button type="submit" disabled={isSubmitting}>保存</button>
    </Form>
  )}
</Formik>
```

### After (React Hook Form + Zod)

```tsx
const schema = z.object({ email: z.email(), name: z.string() });
type Schema = z.infer<typeof schema>;

const {
  register,
  handleSubmit,
  formState: { errors, isSubmitting },
} = useForm<Schema>({
  resolver: zodResolver(schema),
  defaultValues: { email: "", name: "" },
});

const onSubmit = async (values: Schema) => {
  await api.save(values); // RHF が isSubmitting を自動管理
};

return (
  <form onSubmit={handleSubmit(onSubmit)} noValidate>
    <input type="email" {...register("email")} aria-invalid={!!errors.email} />
    {errors.email && <p role="alert">{errors.email.message}</p>}
    <button type="submit" disabled={isSubmitting}>保存</button>
  </form>
);
```

What you gain from migrating: **smaller bundle, fewer re-renders, and unification of types and validation via Zod.** If you also use `shadcn/ui`, use `FormField` instead of `<Field>` and the a11y wiring comes along ([shadcn × RHF × Zod guide](/blog/react-hook-form-shadcn-ui-zod-form-components-guide)).

> **Migrating the validation library (Yup → Zod):** if you converge Yup to Zod at the same time as the form migration, you can reuse the schema for multiple purposes (form, API, DB). But **don't do it all at once.** It's safe in two stages: first make the form wiring RHF and keep the existing Yup running connected via `@hookform/resolvers/yup`, then swap to Zod later.

---

## 8. Cost / performance viewpoint

- **Bundle:** RHF is minimal-class. Formik is large in effective size and disadvantageous on mobile or slow lines. It piles up in a SaaS with many forms.
- **Runtime:** the control-centric Formik increases re-renders in large forms and can worsen INP ([Core Web Vitals optimization](/blog/core-web-vitals-nextjs-inp-lcp-cls-optimization-guide)).
- **Maintenance:** an actively-maintained library is fast to follow new React/Next versions and respond to vulnerabilities. Choosing a sluggish library for new work is a future cost.

From the viewpoint of simultaneously satisfying "fast, cheap, hard to break" too, RHF is the sensible default for new work.

---

## 9. FAQ

**Q. Should I move all existing Formik to RHF?**
A. No need to rush. Leave what works, **write new forms with RHF**, and migrate existing forms you touch along the way — that's enough. The two can coexist.

**Q. Does TanStack Form replace RHF?**
A. Not categorically. For React-only + Zod + shadcn, RHF's overall strength is high. On the other hand, if cross-framework, TanStack unification, or type strictness is a requirement, TanStack Form wins. **Choosing by requirements** is the right answer.

**Q. Can I keep using Yup?**
A. Fine to keep running. But for new work I recommend Zod. You can reuse the schema across form, API, and DB, and TS inference is smooth too ([Zod 4 practical guide](/blog/zod)).

**Q. Is the choice the same for React Native?**
A. RHF officially supports React Native and is strong on mobile too. Formik works as well, but the performance concern is the same.

**Q. So which one?**
A. **When in doubt, React Hook Form.** It's the 2026 default answer for a new React project. Choose TanStack Form only when there's a clear reason (cross-framework, etc.).

---

## Conclusion: when in doubt RHF, but don't forget to "choose by requirements"

Form-library selection should be decided not by fashion but by **the facts of design** —

1. **The default for new work is React Hook Form.** Minimal bundle, the best TS inference, the largest ecosystem and track record.
2. **TanStack Form is a strong rival when there's a clear requirement** (cross-framework, type strictness, TanStack unification).
3. **Formik is not recommended for new work.** Sluggish maintenance, the re-render cost of being control-centric. Migrate existing in stages.
4. **The core of the difference is the re-render strategy.** The heavier the form, the more the value of uncontrolled / field subscription emerges.
5. **Migrate per form, not all at once.** The two can coexist, and you can steadily reduce them with the Boy Scout Rule.

Technology selection is a decision that sways the maintenance cost, hiring, and performance for the next several years. That's exactly why **choosing with a basis and being able to explain that basis** leads to trust.

**If you need form-library selection, a safe migration plan from Formik, or design of a large-scale form foundation, feel free to reach out.** The case study below introduces the process of designing and implementing a B2B SaaS while balancing the validity of technology selection with business constraints.