# Vueform Builder: drag and drop forms that export as Vue components

> Vueform Builder is the visual editor behind the Vueform library, letting developers and non-technical staff assemble forms by dragging elements onto a canvas, then exporting the result as a native Vue component or as JSON. It suits teams where product owners need to change forms without a deploy, and it is a poor fit if you want forms defined purely in code.

**vueform/builder** — Drag and Drop Form Builder for Vueform

- Repository: https://github.com/vueform/builder
- Website: https://builder.vueform.com
- Stars: 717 · Forks: 53
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/vueform-builder

## An editor for a form library, not a standalone form runtime

Vueform Builder is the drag and drop builder for Vueform, the Vue form library. The distinction matters, because the builder is not the thing that renders your production form. It is the authoring tool, and what it produces is either a Vue component you commit to your codebase or a JSON document you store and render.

The stated goal is to let both developers and a non-technical workforce build complex forms without coding. The feature list spells out what that means in practice: a user friendly drag and drop form builder, export of forms as native Vue components, the ability to save, load and render forms as JSON so they can be stored in a database, custom elements and config panels, a built-in theme builder, and the ability to customize the UI.

The dual output is the interesting design decision. Exporting as a native Vue component is the path for a team that wants the form to live in version control with types, props and slots, the same way any other Vue component does. The JSON path is for the opposite situation, where the form has to be editable at runtime by people who are not developers, which means the form definition becomes data that an admin screen can modify and a database can store.

The project also states that the builder can be used online or on your own localhost, and that it integrates into any project. That is a meaningful distinction for an internal tool, since a form builder that only runs on someone else's server is a different proposition from one your team can host itself.

## Four package managers, one --builder flag

Getting started is a project scaffold rather than a library install, and the package manager flag is what selects the builder variant:

```bash
npm create vueform@latest -- --builder
```

The same thing works with the other three common runners:

```bash
yarn create vueform --builder
```

```bash
pnpm create vueform --builder
```

```bash
bun create vueform --builder
```

Note the difference in shape between the npm and the rest. npm needs the double dash to pass arguments through to the create command, while yarn, pnpm and bun forward the flag directly. This is a small thing that costs a confused afternoon if you do not know it.

If you would rather not go through a scaffolder, the project points to an Installation Wizard hosted at builder.vueform.com, which it describes as guiding you through the necessary steps for a hassle-free setup. Either way, the end result is a Vueform Builder instance running on your own machine.

The package on npm is @vueform/builder, and the version in the repository manifest is 1.12.16, matching the most recent release tag. The author listed in the manifest is Adam Berecz.

## What the package manifest reveals about the runtime surface

The package.json is where the shape of the library becomes concrete, and it is more revealing than the feature list.

The package is published under a scoped name, @vueform/builder, and is marked as having no side effects, which lets a bundler tree-shake it. The main entry is index.mjs, and the module type is ESM. Types are shipped alongside the code, with index.d.mts and index.d.ts declared for the package root.

The exports map is the part worth studying. Beyond the main entry, the package exposes its stylesheet as a separate subpath, along with tailwind.css, index.css and a scss/ directory for Sass users. That last one is a real choice rather than an accident, since it means the library can be consumed by a project that has not adopted Tailwind.

There are also subpath exports for locales, with each locale directory mapped to its own index.mjs, and for plugins, including a named plugin/elementSelector export pointing at its own index.mjs. There is a separate plugin entry with its own type declarations, and a standalone preset exported as presets/simple.

The vite/ entry point is exported as well, as vite.js with vite.d.ts, which is the integration surface for Vite projects. A nuxt/ directory sits at the root of the tree, and the presence of vite.js, the Nuxt directory and a Tailwind stylesheet together tell you the intended frameworks: Vite for Vue apps, Nuxt for server-rendered ones, Tailwind for styling.

## Where a visual builder earns its keep, and where it does not

The case for this kind of tool is strongest when the form changes often and the person who wants the change does not write code. A product team running experiments on a checkout flow, a support team that needs a new field for a ticket type, an operations team that needs to capture a different set of attributes per request. In that setting, a JSON-backed builder that writes to a database removes a request-to-deploy cycle for every field change.

The same tool is a liability in a different setting. If a form is stable, small, and written alongside the component that consumes its values, a builder adds a layer without removing work. Now there is a schema to keep in sync with the code that reads it, an editor whose output nobody reviews, and a rendering path that has to be understood by whoever debugs the form later. Hand-written markup for a four-field form is easier to reason about than a builder plus a JSON blob.

The custom elements and config panels feature is where the tool gets interesting for the first group. It means the builder is not limited to the field types the library ships with, so a team can add its own component and expose its own settings. Combined with the built-in theme builder, that makes it plausible for the builder output to look like the rest of the product rather than a generic form bolted on.

The online or localhost distinction also matters more than it first appears. Running the builder on your own machine means form definitions never have to pass through a third-party service, and it means the builder can be part of an internal toolchain that a non-technical user opens behind your own authentication.

## The licence is the first thing to read

The repository ships a LICENSE.txt, and the package manifest records the licence as SEE LICENSE IN LICENSE.txt rather than as a standard identifier, which is why GitHub cannot classify it. The README links to a licence agreement page on the vendor's own site rather than restating the terms, and it is the only licence information the project documentation gives.

This is the one part of the evaluation that cannot be summarised, so read the file before you build anything on it. A custom licence is not automatically a problem, and a permissive one is not automatically a problem either, but the difference matters when you are shipping a form builder inside a commercial product, when your legal team needs to know what they may redistribute, and when a customer asks whether they can keep the forms they designed after you stop selling to them.

The versioning is regular and the release tags are the useful signal. The recent history shows 1.12.16 on 2026-09-08, 1.12.15 on 2026-07-21 and 1.12.14 on 2026-06-22, a steady sequence of patch releases rather than occasional large ones. The last push was on 2026-09-08, the same day as the newest tag, so the working tree and the published version are in step.

There is also a CHANGELOG.md at the root of the repository, which is where you should look before upgrading a project that has forms stored as JSON, since a change to the schema of a stored form is a different kind of risk from a change to a rendering component.

## Conclusion

Vueform Builder fits a team that has already chosen Vueform as its form layer and wants a visual editor for the people who own the forms, since it exports both a native Vue component and a JSON representation and can be run on your own machine rather than only on the hosted builder. It is the wrong choice if your forms are simple enough to be written by hand, if you need a headless builder without a Vue runtime, or if you are not prepared to accept a proprietary licence that GitHub cannot classify. Before adopting it, run npm create vueform@latest -- --builder on a scratch project, check the exported component against your existing form code, and read LICENSE.txt, because the last push to the repository was on 2026-09-08 and the current version is 1.12.16.

## FAQ

### How do I install Vueform Builder?

Run npm create vueform@latest -- --builder, or the equivalent yarn create vueform --builder, pnpm create vueform --builder or bun create vueform --builder. For a manual setup, the project points to an Installation Wizard at builder.vueform.com.

### What can I export from Vueform Builder?

Forms can be exported as native Vue components, and they can also be saved, loaded and rendered as JSON so that form definitions can be stored in a database and edited at runtime.

### Does Vueform Builder work with Nuxt and Tailwind?

The package exports a dedicated vite entry point, the repository contains a nuxt/ directory, and separate exports exist for tailwind.css and for a scss/ directory, so the builder can be used with Vite, Nuxt and either Tailwind or Sass styling.

### Can I run Vueform Builder on my own machine?

Yes. The project states the builder can be used online or on your localhost, and the create command scaffolds a Vueform Builder instance on your own machine.

### What licence does Vueform Builder use?

The repository ships a LICENSE.txt and the package manifest records the licence as SEE LICENSE IN LICENSE.txt, so it is a custom licence rather than a standard one. The README links to the licence agreement page on the vendor's site.

## Sources

- [Issues](https://github.com/vueform/builder/issues)
- [Project website](https://builder.vueform.com)
- [README](https://github.com/vueform/builder/blob/main/README.md)
- [Releases](https://github.com/vueform/builder/releases)
- [vueform/builder on GitHub](https://github.com/vueform/builder)

---

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