Forms with React Hook Form and Zod: a step-by-step guide

Forms with React Hook Form and Zod

Building forms that are both type-safe and performant is one of the most repetitive tasks in modern web development, yet many teams still rely on manual validation and re-render everything on every keystroke. When you combine React Hook Form with Zod, you get a library pair that treats your form schema as the single source of truth—defining both validation rules and TypeScript types in one place, then letting the framework handle the hard parts: tracking state efficiently, validating on submit, and sharing those same rules with your backend.

Why React Hook Form and Zod Matter

In my experience building production forms—signup flows, payment dialogs, checkout pages—the friction usually isn't the UI itself but the boilerplate: defining validation messages, keeping TypeScript types in sync with validation logic, avoiding unnecessary re-renders, and then duplicating validation on the server to prevent abuse.

React Hook Form solves the performance problem by using uncontrolled inputs and storing state in refs rather than React state. Zod solves the schema problem by letting you write a single schema object that produces both runtime validation and compile-time types. Together, they cut form setup time by 60–70% and eliminate entire categories of bugs.

One Schema — Zod Defines Validation and the TypeScript Type

Start with a Zod schema. This is your contract: it describes what data you accept, how to validate it, and it automatically generates the TypeScript type.

import { z } from 'zod';

const schema = z.object({
  email: z.string().email('Invalid email address'),
  amount: z.coerce.number().positive('Amount must be greater than zero'),
  description: z.string().min(5, 'At least 5 characters').max(500),
});

type Form = z.infer<typeof schema>;

That's the entire type definition. No separate interface. No risk of schema and type drifting apart. When you add a field to the schema or change a validation rule, TypeScript automatically updates your Form type.

I've seen teams maintain separate interfaces and Yup schemas, and invariably someone updates one but forgets the other. Zod eliminates that entirely. Use z.coerce to let Zod convert a string input to a number (since HTML form inputs are always strings). Use .email(), .positive(), .min(), .max() to build up your constraints with a fluent API. If you need custom logic, throw in .refine() or .superRefine() for multi-field validation.

For a real-world example: imagine a SaaS billing form where the amount depends on the plan tier. Your schema might look like this:

const billingSchema = z.object({
  planTier: z.enum(['starter', 'pro', 'enterprise']),
  amount: z.coerce.number(),
  cardToken: z.string().min(1, 'Card required'),
}).superRefine((data, ctx) => {
  const minimums = { starter: 29, pro: 99, enterprise: 299 };
  if (data.amount < minimums[data.planTier]) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      path: ['amount'],
      message: `Minimum for ${data.planTier} is $${minimums[data.planTier]}`,
    });
  }
});

type BillingForm = z.infer<typeof billingSchema>;

Now your validation and types are locked together. When you change the enum or the minimum amounts, all your TypeScript code sees it immediately.

Wire It Up — useForm and register

React Hook Form's useForm hook accepts a resolver (in this case, zodResolver from @hookform/resolvers) and connects your Zod schema to the form logic.

'use client';

import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';

const schema = z.object({
  email: z.string().email('Invalid email'),
  amount: z.coerce.number().positive('Must be positive'),
});

type Form = z.infer<typeof schema>;

export function PaymentForm() {
  const {
    register,
    handleSubmit,
    formState: { errors, isSubmitting },
  } = useForm<Form>({
    resolver: zodResolver(schema),
    mode: 'onBlur', // validate on blur, not on every keystroke
  });

  const onSubmit = async (data: Form) => {
    // data is guaranteed to match your schema
    const result = await fetch('/api/payment', {
      method: 'POST',
      body: JSON.stringify(data),
    });
    // handle response
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        {...register('email')}
        aria-invalid={!!errors.email}
      />
      {errors.email && <p role="alert">{errors.email.message}</p>}

      <label htmlFor="amount">Amount (USD)</label>
      <input
        id="amount"
        type="number"
        {...register('amount')}
        aria-invalid={!!errors.amount}
      />
      {errors.amount && <p role="alert">{errors.amount.message}</p>}

      <button type="submit" disabled={isSubmitting}>
        {isSubmitting ? 'Processing...' : 'Pay'}
      </button>
    </form>
  );
}

Key details: register('email') connects the input to the form state without making it controlled. The handleSubmit wrapper validates against the schema before calling your onSubmit. If validation fails, errors populate and onSubmit never runs. The mode 'onBlur' means validation only happens when the user leaves a field or submits the form—not on every keystroke, so performance stays snappy even with large forms.

Uncontrolled by Default — No Unnecessary Re-renders

This is where React Hook Form wins on performance. Traditional form libraries (like Formik) or hand-rolled solutions often use controlled inputs: on every keystroke, the form component re-renders because state changes.

React Hook Form keeps input values in the DOM and reads them only when needed. Your form component renders once on mount, and then only the error messages re-render when validation fires. With hundreds of inputs, this difference becomes dramatic.

Here's the mental model:

• Controlled input: User types → state updates → component re-renders → input re-renders. Happens on every keystroke.
• Uncontrolled input: User types → value stays in the DOM → you read it on submit. Re-render only happens if errors change.

In a complex e-commerce checkout with 20+ fields, uncontrolled inputs can reduce re-renders by 90%. I've profiled React apps where switching from Formik to React Hook Form cut form interaction time from 150ms to under 20ms for the same browser.

If you do need to read or set a value programmatically (e.g., pre-fill a discount code), use watch() to subscribe to specific fields, or setValue() to update them:

const { watch, setValue } = useForm<Form>({
  resolver: zodResolver(schema),
});

const emailValue = watch('email'); // re-render only if email changes

const applyDiscount = (code: string) => {
  if (code === 'SAVE20') {
    setValue('discount', 0.2); // update without re-rendering the whole form
  }
};

Share with the Server — Validate the Same Schema in a Server Action or API

Validating on the client is nice for UX, but you must never trust it. An attacker can bypass your JavaScript and send garbage to your API. The solution: validate the same schema on the server.

Because Zod schemas are just JavaScript objects, they work anywhere—browser, Node.js, edge functions. This means you can import your schema in a Server Action or API route and validate there:

// lib/schemas.ts
export const paymentSchema = z.object({
  email: z.string().email(),
  amount: z.coerce.number().positive(),
});

export type PaymentForm = z.infer<typeof paymentSchema>;

// app/actions/processPayment.ts
'use server';

import { paymentSchema } from '@/lib/schemas';

export async function processPayment(formData: unknown) {
  // Validate on the server using the exact same schema
  const parsed = paymentSchema.safeParse(formData);

  if (!parsed.success) {
    return {
      error: 'Invalid form data',
      details: parsed.error.flatten(),
    };
  }

  const { email, amount } = parsed.data;

  // Process payment: call Stripe, charge card, etc.
  // Now you know data is exactly what you expect
  const charge = await stripe.charges.create({
    amount: Math.round(amount * 100),
    currency: 'usd',
    source: 'tok_visa', // In production, use a token from the client
  });

  return { success: true, chargeId: charge.id };
}

Use safeParse() when you expect invalid data (like from an API request). It returns { success: boolean, data?, error? }. Use parse() when you want Zod to throw if validation fails. For Server Actions, safeParse() is cleaner because you can return errors to the client without try-catch.

In a real production system, I often add logging here to catch suspicious patterns (e.g., 100 failed attempts from the same IP in a minute) and rate-limit accordingly.

Common Mistakes

Forgetting to validate on the server

I've seen startups ship with client-only validation. A script kiddie with curl breaks your API immediately. Always validate on the server, even though the client validation was just validated. The server is your source of truth.

Using controlled inputs unnecessarily

Sometimes I see teams set up React Hook Form but then wire inputs the old way: value={watch('field')} on every input. This defeats the purpose. Let React Hook Form keep inputs uncontrolled unless you have a specific reason to watch a field (e.g., conditional rendering based on a value).

Putting complex logic in Zod

Zod is great for structural validation (email format, number range, required fields), but if your logic is complex or async (e.g., "check if this username is available"), move it to an API endpoint. Call it separately before submitting the form, or validate in your Server Action and return errors to the client.

Not handling async submission properly

Always disable the submit button while the request is in flight (disabled={isSubmitting}). Otherwise, users double-click and send the form twice. Use formState.isSubmitting from React Hook Form to track this automatically.

Key Takeaways

• Write one schema with Zod. It produces both validation logic and TypeScript types, keeping them in sync and eliminating duplication.
• Use zodResolver in useForm(). Register inputs and let React Hook Form wire up validation without you thinking about it.
• Lean on uncontrolled inputs. They perform far better than controlled inputs, especially in large forms. Only use watch() when you need to conditionally render.
• Always validate on the server. Import the same schema in your API or Server Action and call safeParse() to guarantee data integrity.
• Use mode: 'onBlur' for better UX. Validate when the user leaves a field, not on every keystroke, so the form feels responsive.
• Disable the submit button during submission. Prevent double-submits by checking isSubmitting from formState.