React Hook Form DevTools is a one component overlay for form state

One component, one prop, mounted next to the form

React Hook Form DevTools is a React component whose stated goal is to help you debug forms when working with React Hook Form and to give more insight into a form's details. It is published to npm as @hookform/devtools, the project page is react-hook-form.com/dev-tools, and the licence is MIT.

The integration surface is unusually small. You render a DevTool component and hand it the control object that useForm returns. There is no provider, no global store, no context to configure, and no wrapper around your form. The panel is a sibling of your form in the tree, and it reads state from the same control instance your inputs are registered against.

That design is what makes it useful. A form with a dozen fields, conditional rendering and asynchronous validation can be hard to reason about from the outside, because the visible DOM does not always match what the form library believes. A panel that shows the internal values and error state in one place removes the guesswork, and it does so without asking you to instrument every field.

The trade-off is that the panel is a rendered overlay in your application tree. It is not a browser extension, so it follows your component tree, your CSS and your build, which is convenient for local debugging and awkward if you want the same view on a deployed environment.

Installing it and dropping it into a form

The install is a single development dependency, and the documentation marks it as such with the -D flag, which keeps it out of a production dependency tree:

    $ npm install @hookform/devtools -D

The quickstart example that follows is a complete small component. It imports React, useForm from react-hook-form and the DevTool component, then wires them together:

import React from 'react';
import { useForm } from 'react-hook-form';
import { DevTool } from '@hookform/devtools';
import './App.css';

const App = () => {
  const { register, control, handleSubmit } = useForm({
    mode: 'onChange',
  });

  return (
    <>
      <DevTool control={control} placement="top-left" />

      <form onSubmit={handleSubmit((d) => console.log(d))}>

The second half of the example is the form itself, an input registered through the register function and a submit button:

        <h1>React Hook Form DevTools</h1>

        <label>Test</label>
        <input name="test" ref={register} />

        <input type="submit" />
      </form>
    </>
  );
};

export default App;

Two details in that example are worth carrying over. The form is created with mode set to onChange, so validation runs on every change rather than on submit, which is what makes the panel show live error state. And the placement prop positions the panel, with top-left used in the example.

What the control prop gives you, and what the docs leave out

Everything the panel shows comes from the control object returned by useForm, which is why the component works alongside the rest of the library rather than replacing any part of it. The DevTool does not own your form state, does not submit anything, and does not change how validation behaves. It observes.

What you see on the panel is not spelled out in the project documentation, and that is a real gap. The README states the goal of giving more insight into a form's details and shows a screenshot of the panel, but it does not enumerate the fields displayed, describe the filtering or search behaviour, or list the full set of props. The only two props visible in the example are control and placement.

So the honest position is that the component is easy to try and easy to install, but the documentation is a quickstart rather than a reference. If you need a specific piece of state to be visible, such as whether a field is dirty, or the values of a field array, you will have to look at the panel yourself or read the source in src/.

For comparison, the alternative approach is to read the same state yourself. React Hook Form exposes that state through the form instance, so a developer can build a small panel with React state or a subscription to a single field and get exactly the information they want. The DevTool saves that work and gives a broader view, at the cost of the black box.

A rollup build with five distribution entry points

The packaging in the package.json shows how deliberately this is shipped. The CommonJS main points at dist/index.js. There is a UMD build at dist/index.umd.development.js, published through the umd:main field and also used for the unpkg and jsdelivr fields. An ES module build sits at dist/index.esm.js behind the jsnext:main field, and type declarations are emitted to dist/index.d.ts. The source entry is src/index.tsx.

Two details in that metadata matter in practice. The sideEffects field is set to false, which lets a bundler drop the import when nothing uses it, a meaningful optimisation for a component that only appears in development. And the files array publishes only dist, so the source, the tests and the tooling stay out of the tarball.

The build itself is rollup driven, with a prebuild step that clears dist using rimraf, and a small script that writes the CommonJS entry file before rollup runs. Publishing is gated: prepublishOnly runs the lint script, the type check with tsc --noEmit and the build, in that order, so a broken type check blocks a release.

Versioning goes through changesets. The .changeset directory and the changeset and release scripts are present, and the postversion script pushes the commit and the version tag to the origin.

Storybook, Jest and a Vite example app in the same tree

The repository carries the tooling you would expect for a component library, and the scripts section of package.json lists them in full.

There is a Storybook setup, with a .storybook directory and start-storybook -p 6006 for development and a separate build-storybook script. Tests run under Jest with the --runInBand flag, and a watch variant adds watchAll and coverage. A separate type-only lint script runs tsc --noEmit, and the format script runs prettier over JavaScript, TypeScript, Markdown and JSON.

Git hooks are handled by husky, with a prepare script that installs them, so formatting and commit conventions are enforced locally rather than only in CI.

The example directory is a full application rather than a snippet, with its own package.json, tsconfig.json and a vite.config.ts, plus a yarn.lock. That gives you a sandbox to try the panel against a real form. The fact that the example is a Vite project also tells you something about the audience, since it is set up the way a current React project would be set up.

The published package version in the metadata is 4.4.0, and the repository also ships a CHANGELOG.md. The last push to the master branch was on 2026-08-17, while the most recent tagged release listed for the repository is v4.3.3 from 2024-12-16, with v4.3.2 from three days earlier and v4.3.1 from 2023-03-06.

A dev dependency that will ship if you forget it

The main risk with this package is mundane and entirely avoidable: it is a debug overlay, and debug overlays that stay in the bundle are visible to your users.

Nothing in the component checks an environment variable or a development flag. The control comes from your code, so the panel renders whenever the component is in the tree. The mitigation is structural rather than built in. Install with -D so it lands in devDependencies, and rely on the sideEffects false flag in the package metadata so that a bundler can drop the import when it is unused.

The second limitation is the release gap. The package metadata declares version 4.4.0 while the latest tag is v4.3.3 from 2024-12-16, and the last push was on 2026-08-17. That means the published tarball and the working tree are not the same thing, and it is not clear from the repository alone which changes have shipped. A team that depends on a specific fix should read the CHANGELOG.md and compare it with the tag, rather than trusting the version string in the metadata.

The third is scope. The component requires a control object, so it only applies to React Hook Form. There is no equivalent for other form libraries in this repository, and there is no way to inspect a form that is not mounted in React.

Editorial conclusion

React Hook Form DevTools suits any team that already uses React Hook Form and wants to see form state without writing a panel of their own, and it is the wrong tool for a project that is not already on React Hook Form, since it only accepts a control object. Before adding it, install it as a development dependency and confirm your build strips it, then check the version you actually resolve, because the package metadata says 4.4.0 while the latest tag is v4.3.3 from 2024-12-16.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-hook-form/devtools on GitHub
4. README
5. Releases