# formBuilder: a jQuery drag and drop form editor you host yourself

> formBuilder is a jQuery plugin that renders a drag and drop form editor inside your own page and outputs a JSON schema. It suits teams already on jQuery who want the builder embedded, not a hosted form service.

**kevinchappell/formBuilder** — A jQuery plugin for drag and drop form creation

- Repository: https://github.com/kevinchappell/formBuilder
- Website: https://formbuilder.online
- Stars: 2,708 · Forks: 1,414
- Language: JavaScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/kevinchappell-formbuilder

## What formBuilder actually solves, and for whom

The project describes itself as "A jQuery plugin for drag and drop form creation." That sentence is the whole scope. You get an editor surface that a non-developer can drag controls onto, and you get a schema out of it. You do not get a form hosting service, a submission endpoint, or a database. The README links to a hosted demo at formbuilder.online and to a separate API demo, but the artifact you install is a plugin that mounts on a DOM element.

The audience is narrow and specific. It is a team with an existing jQuery codebase, or a server-rendered admin panel where adding a React toolchain is a bigger change than adding one script tag. The package.json lists jquery-plugin among its keywords and the entry point is dist/form-builder.min.js, which tells you the distribution model: a browser bundle, not an ES module you tree-shake.

If your application is already component-based, the plugin's model of mounting onto a selector and reading state back out of it will feel like a step backwards. That is not a defect in the plugin. It is the boundary of what a jQuery plugin can be.

## The editor and the renderer are two separate builds

This is the design decision that matters most and it is easy to miss. The package config block declares two distinct source sets: formBuilder, whose JS is src/js/form-builder.js and whose Sass is src/sass/form-builder.scss, and formRender, whose JS is src/js/form-render.js and whose Sass is src/sass/form-render.scss. They are built separately.

The practical consequence: the editor is not required at runtime for a user filling in a form. You store the schema the editor produced, and on the public-facing page you load only the renderer. That keeps the drag and drop machinery, the control palette and the editor styling off the page that actual respondents see. It is a meaningful split, and it is the reason the renderer exists as its own bundle at all.

The repository also ships a plugins concept. The config points at src/js/control_plugins/ as the plugins directory, and there is a build:plugins script in package.json. Custom control types live there rather than in the core file. The README does not document the plugin authoring interface; it points at formbuilder.online/docs instead, so treat the docs site as the real reference for extending the control set.

## Installing formBuilder and mounting a first editor

The README gives a single usage example, and it is the whole integration surface for the default case. You select an element and call the plugin on it inside a jQuery ready callback.

```javascript
jQuery($ => {
  $('#fb-editor').formBuilder()
})
```

That means the page needs jQuery loaded before this runs, and it needs an element with the id fb-editor to exist. The plugin mounts the editor into that element rather than replacing it. If the selector matches nothing, nothing happens and no error is thrown, which is the usual failure mode for a missing container.

The package is published to npm under the name formBuilder, and the main field points at dist/form-builder.min.js. A typical install is:

```bash
npm install formBuilder
```

After install, the dist directory in the package contains the built bundles. The files array in package.json includes dist, docs and src, so the source is shipped alongside the build. Loading the stylesheet matters as much as loading the script; the Sass sources are src/sass/form-builder.scss for the editor and src/sass/form-render.scss for the renderer, and the built CSS ships in dist.

To confirm the install worked, open the page and check that the control palette appears inside your container. If the container is empty, the script or the stylesheet did not load, or the selector did not match.

## Browser support is broad, server support is absent

The README's support table lists Chrome, Firefox, Safari, Opera and Edge, each marked "Latest". That is a deliberately shallow promise: current versions only, no legacy matrix. There is no Internet Explorer column. If your users include anyone on an older browser, the README offers no guidance and no polyfill list.

More importantly, everything about the project is client-side. The plugin builds a schema in the browser. There is no server component in the repository, no submission handler, and no storage. The Dockerfile in the repository is not a runtime for the form builder at all: it is a python:3.9-slim-buster image that copies ./docs and mkdocs.yml, installs mkdocs, exposes port 8123 and runs mkdocs serve --dev-addr=0.0.0.0:8123. That container serves the documentation site. Anyone who finds the Dockerfile and assumes it deploys the form builder will be surprised.

So the integration work is yours: persist the schema, validate submissions, and decide what the server accepts. The plugin hands you structured data and stops there.

## Where formBuilder is the wrong tool

If you need a form that collects responses without you running a backend, formBuilder is the wrong choice. It produces a schema and renders inputs. It does not receive submissions. A hosted form service solves that problem and this project does not attempt to.

If your stack is React, Vue or Angular, the mounting model is a friction point. You will be wrapping a jQuery plugin in a lifecycle hook and manually tearing it down, and the README offers no guidance for that. The README does link to a separate Angular 2/4 port maintained by another author, which is an acknowledgment that the core plugin is not framework-native. That link points at a third-party repository, so its maintenance is not covered by anything in this repository.

There is also a translation gap. The README states the project is translatable and then asks for help: "As formBuilder usage grows so does its need to be available in multiple languages." Language strings live in a separate repository, formBuilder-languages, with its own contributing guide. If you need a locale that is not yet covered, you are contributing to that other repository, not configuring an option here. The README does not enumerate which locales already exist.

## How it compares to a schema-driven renderer like react-jsonschema-form

The closest structural alternative is a renderer driven by JSON Schema, such as react-jsonschema-form. The difference is where the schema comes from and who owns its shape.

react-jsonschema-form takes a schema you wrote by hand, or generated elsewhere, and renders a form from it. The schema is the input and it conforms to a published standard. formBuilder inverts that: the schema is the output, produced by a person dragging controls in a browser, and its shape is formBuilder's own, not JSON Schema. That is the trade-off in one line. You gain a non-developer editing path and lose portability of the resulting schema.

If your forms change often and the people changing them are not engineers, formBuilder's direction is the useful one. If your forms are stable and defined by a backend contract, writing the schema directly and rendering it is less machinery. The two are not interchangeable, and picking formBuilder means committing to its schema format as your storage format.

## Licence, releases and what upgrades cost you

formBuilder is MIT licensed, stated in both the README badge area and the license field of package.json. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice travel with it. That is the general shape of the licence, not legal advice for your situation.

The release cadence is visible in the version history. v3.22.1 landed on 2026-05-08, v3.22.2 on 2026-06-20, and v3.23.1 on 2026-06-26. The last push to the repository was on 2026-09-13, so the project is not archived and work has continued past the most recent tagged release. The package version in package.json matches v3.23.1, so the published package and the repository are in step.

Upgrade cost is the part the README does not address. There is no migration guide in the README, and no statement about schema compatibility between major versions. Because the schema is your storage format, a change to how controls serialize is a data migration, not a library bump. Before upgrading across a major version, read CHANGELOG.md in the repository and test an existing stored schema against the new renderer. That file is the only changelog reference the README points to.

## Conclusion

Adopt formBuilder if you already ship jQuery, want the editor embedded in your own page, and can accept a browser-only builder that emits a JSON schema you render yourself. Do not adopt it if you need server-side rendering, a hosted form endpoint, or a framework-native component. Before committing, verify two things: that the rendered output of formRender matches the markup your backend expects, and that the control plugins your forms rely on still load under the current build config, since the README documents neither.

## FAQ

### How do you use formBuilder?

Load jQuery, then call the plugin on a container element inside a ready callback, as the README shows with $('#fb-editor').formBuilder(). The editor mounts into that element and produces a schema you store and later render.

### How do you install formBuilder?

The package is published to npm under the name formBuilder, so npm install formBuilder pulls it in, and the main entry is dist/form-builder.min.js. The dist directory also contains the built stylesheets for the editor and the renderer.

### Can formBuilder be used with Angular?

The core plugin is a jQuery plugin and the README does not document an Angular integration. The README does link to a separate Angular 2/4 port hosted in another author's repository, whose maintenance is outside this project.

## Sources

- [kevinchappell/formBuilder on GitHub](https://github.com/kevinchappell/formBuilder)
- [License: MIT](https://github.com/kevinchappell/formBuilder/blob/master/LICENSE)
- [Project website](https://formbuilder.online)
- [README](https://github.com/kevinchappell/formBuilder/blob/master/README.md)
- [Releases](https://github.com/kevinchappell/formBuilder/releases)

---

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