# validator.js, a dependency-free form validation library for the browser

> validator.js is a small JavaScript form validation library that ships with no dependencies and a UMD build, aimed at the case where you want to validate a form in the browser without pulling in a framework. The repository is a Lerna monorepo with separate packages for the library, a hook layer and a documentation site, and its releases have not moved since 2023.

**jaywcjlove/validator.js** — :interrobang: Lightweight JavaScript form validation, that had minimal configuration and felt natural to use. No dependencies, support UMD. 

- Repository: https://github.com/jaywcjlove/validator.js
- Website: https://git.io/validatorjs
- Stars: 555 · Forks: 114
- Language: TypeScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jaywcjlove-validator-js

## A small library with no dependencies and a UMD build

validator.js is described as lightweight JavaScript form validation, that had minimal configuration and felt natural to use, with no dependencies and UMD support.

Those three claims define the package precisely, and each of them is a design decision rather than a feature list entry.

No dependencies means nothing else gets installed alongside it. That matters more than it sounds in a front end, where a single validation import can pull in a utility library, a type package and a polyfill. A dependency-free validation library can be dropped into a page with a script tag and nothing else, which is the situation the UMD build is for.

UMD, the Universal Module Definition, is the wrapper format that lets one file work as a CommonJS module, as an AMD module and as a plain script that defines a global. For a library whose stated promise is minimal configuration, a build that works in a script tag is part of the promise rather than a legacy courtesy.

The other claim, that it felt natural to use, is the one that cannot be checked from a package manifest, and it is the one that decides whether a form validation library is adopted. A validation library is used once, at every form in the application, and it is used by whoever is building that form. If the API is awkward, the workaround is to not validate, and the validation quietly disappears. So the naturalness of the API is the load-bearing property, and it is the reason the project is worth a closer look rather than a dependency check.

The primary language is TypeScript, the homepage is git.io/validatorjs, and the topics list names the ground it covers: assert, form, form-validation, javascript, sanitize, validate, validation, validator and validatorjs. The sanitize entries are worth noting, since sanitisation and validation are different jobs and having both in one library is a design choice rather than a given.

## A Lerna monorepo with three moving parts

The repository is a monorepo, and the root manifest shows the shape.

The workspaces are `packages/*` and `website`, and the build scripts name two of the packages: `validator.tool` and `@validator.tool/hook`. So the published surface is split between a package called validator.tool, which is the library itself, and a scoped package called the hook, which is something the library can use.

The scripts are Lerna commands throughout.

```json
    "test": "tsbb test --env=jsdom",
    "coverage": "tsbb test --env=jsdom --coverage",
    "start": "lerna exec \"npm run start\" --scope website",
    "build": "lerna exec \"npm run build\" --scope website",
    "lib": "npm run lib:build && npm run hook:build",
```

The two-part build script is the clearest statement of the structure. `lib:build` builds the validator.tool package with `lerna exec`, and `hook:build` builds the hook package with `tsbb build`. The `lib:watch` script does the same with `tsbb watch`, so the development loop for both packages is a watch build.

The test setup is worth a closer look, because it tells you what the library is for. The tests run through `tsbb test --env=jsdom`, which means the test environment is jsdom, a DOM implementation in JavaScript. A validation library that is unit tested against a DOM is a library that operates on DOM elements and their events, not on plain data objects. That is a different design from schema-based validation libraries, and it lines up with the UMD build and the script-tag use case.

The Jest configuration in the root manifest confirms the layout. The test match pattern is `packages/**/__tests__/*.{js,jsx,ts,tsx}` and coverage is collected from the src directories of the same packages, so the packages hold source in `src` and tests in `__tests__`, and the website is excluded from both.

The toolchain is Lerna 6 with tsbb as the build tool, and the presence of `lerna bootstrap` and `lerna bootstrap --hoist` scripts is a detail that dates the setup, since those commands were Lerna's own answer to npm workspaces and have since been deprecated in favour of letting npm or Yarn do it.

## What the repository front page actually is

There is something to say here that a review of the package would not normally mention, and it affects how you evaluate the project.

The README of this repository opens with a long block of links to the maintainer's own macOS applications, each with an icon and a link, and there is a note saying that using one of those apps is also a way to support the author. The validator.js section with its heading and the project badges comes after all of that.

So the README of the library itself is short, and the surface the repository presents to a visitor is mostly the maintainer's other work. That is a fact about the project rather than a criticism of the library, but it has two consequences worth naming.

The first is that the documentation for the library lives in the `website/` workspace rather than in the README, and the root scripts exist to build and serve it, with `start` and `build` both scoped to the website package. So the documentation is a VitePress-style site in a separate directory of the monorepo, and the way to read the API is to run the site locally.

The second is that the signals in the repository root are about the author's wider output rather than about this package's health. If you are assessing whether to adopt the library, the useful things to look at are the release history, the package contents and the tests, not the front page.

The homepage field in the manifest points at jaywcjlove.github.io/validator.js, which is the documentation site rather than the repository, which reinforces the point that the docs are a separate thing from the code.

There is a `.npmignore` as well as a `.gitignore`, which is what you would expect for a package that publishes from the repository root, and a `renovate.json` for automated dependency updates.

## Maintenance state and the release gap

The version history is the main thing to weigh, and it is mixed.

The recorded releases are v2.2.6 from 2023-11-26, v2.2.5 from 2023-04-05 and v2.2.4 from 2022-05-15. The last push to the repository was on 2026-04-23. The default branch is `master`, and the project is not archived.

So the branch has moved within the last six months while the last tagged release is nearly three years old. That gap is the thing to think about, and it has two plausible explanations. Either the recent commits are maintenance and documentation work that has not been released, or they are experiments in the monorepo that have not settled into a version. Either way, the version you can install from a package registry is v2.2.6, and that is what most people will be running.

The release process is Lerna's, with the `version` script running `lerna version --exact --force-publish --no-push --no-git-tag-version`. The flags matter: the version is forced to be exact rather than derived from a semver range, every package is published rather than only the changed ones, and the push and git tag are suppressed, which means tagging is done separately from the publish. That is the standard Lerna setup for a monorepo where packages are versioned in lockstep, which fits a library and a hook package that ship together.

The licence is the other open question. The repository shows no licence type in its metadata, while the manifest itself does not carry a licence field. For a package with no dependencies, the MIT licence is the usual choice in this ecosystem, and the repository does have a LICENSE file, but the metadata gap is worth closing before you rely on it, particularly for a package you might vendor or redistribute.

The topics list has a single entry, hacktoberfest, which as with other packages in this queue suggests small, scoped contributions rather than a maintained feature roadmap.

## How it compares to the alternatives

Form validation in the browser has several established answers, and the differences are about where the rules live.

Native HTML constraint validation is the zero-dependency answer that always ships. The `required` attribute, the `type` attribute, `pattern` and the constraint validation API put basic checking in the markup with no JavaScript at all. What it cannot do is cross-field rules, which is exactly the case most forms need, such as a password confirmation that must match or a date range that must be ordered.

The jQuery Validation plugin is the older scripted answer, and it is the closest in spirit to a lightweight library: a set of rules attached to a form, with messages, and no dependency beyond jQuery itself. Its age is both its weakness and its reason for existing, since it is still in every large jQuery codebase.

Schema-based libraries are the modern answer and take a different approach. Rather than attaching rules to DOM elements, they define a schema for the data and validate a plain object against it, and then a thin adapter connects the schema to the form. That separation is the big advantage, because the same schema can be validated on the server, which is the point of libraries with matching server-side implementations. The cost is a schema language, a build step or a runtime parser, and usually a framework integration.

validator.js sits between the native and the schema approaches. It is a DOM-oriented library with rules and messages and no dependency, which makes it the natural choice for a page that needs real client-side validation without a framework and without a build step, and the natural wrong choice for a codebase that wants one source of truth for its validation rules.

One limitation follows from the dependency-free and UMD combination. A library with no dependencies has to implement its own regular expression handling and its own string helpers for the locale-aware checks that validation needs, and the more of those it offers, the larger the surface for edge cases in unusual locales. If you are validating names or addresses from a global user base, that is worth testing on the specific data you have.

## Conclusion

validator.js suits a project that already has its own front end and wants form validation with no framework and no dependency tree, and it suits a page that needs a small amount of client-side checking without a build step. It does not suit a team that wants a typed validation schema shared with the back end, since the type definitions here describe the library rather than your data. Verify first that the release you install matches the API the documentation site describes, given that the last tagged release is v2.2.6 from 2023-11-26, that the package you want is the one you need from the monorepo, and that the licence file in the repository says what you expect, since the repository shows no licence type in its metadata.

## FAQ

### What is validator.js?

It is a lightweight JavaScript form validation library described as having minimal configuration and feeling natural to use, with no dependencies and UMD support. The source is TypeScript and the package is published as validator.tool within a Lerna monorepo.

### How is the validator.js repository structured?

It is a Lerna monorepo with the workspaces packages/* and website. The published packages are validator.tool and @validator.tool/hook, the documentation lives in the website workspace, and the root scripts use lerna exec to build each package with tsbb.

### How are validator.js tests run?

With npm test, which runs tsbb test --env=jsdom, and npm run coverage for the coverage variant. The Jest configuration matches tests in the packages __tests__ directories and collects coverage from the packages src directories, so the tests run against a DOM implementation.

### Where is the documentation for validator.js?

In the website workspace of the monorepo, which the root start and build scripts serve and compile with lerna exec scoped to website. The manifest homepage points at the published documentation site, and the README of the repository itself is mostly links to the maintainer's other applications.

### Is validator.js still maintained?

The recorded releases are v2.2.6 from 2023-11-26, v2.2.5 from 2023-04-05 and v2.2.4 from 2022-05-15, while the last push to the repository was on 2026-04-23. The branch is active but no release has been tagged since 2023, and the repository shows no licence type in its metadata.

## Sources

- [Issues](https://github.com/jaywcjlove/validator.js/issues)
- [jaywcjlove/validator.js on GitHub](https://github.com/jaywcjlove/validator.js)
- [Project website](https://git.io/validatorjs)
- [README](https://github.com/jaywcjlove/validator.js/blob/master/README.md)
- [Releases](https://github.com/jaywcjlove/validator.js/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jaywcjlove-validator-js