SurveyJS Survey Creator: An Embeddable JSON Form Builder You Host Yourself

The Problem: Forms That Keep Changing After You Ship

Hard-coded forms age badly. A field is added, a question becomes conditional, a step gets reordered, and each change is a frontend release. Survey Creator targets that specific cost: it is an editor your users operate inside your own application, and the artifact it produces is a JSON definition rather than compiled markup. The README frames the audience directly, listing single-tenant and multi-tenant SaaS applications among the intended deployments, plus any application that needs full control over form and response data. That last phrase is the real filter. If you are content to let a vendor hold your form definitions, this project is more machinery than you need. If your forms are part of your product's data model, or your customers ask where their data lives, an editor that runs in the browser and posts nowhere is the point.

What Actually Happens Between the Editor and Your Database

The README describes a four-step loop, and it is worth reading literally because it defines the integration surface. The visual editor generates a JSON definition for each form. Your application saves that definition to your database, loads it back into Survey Creator for editing, renders it with the SurveyJS Form Library, and stores submitted responses in your own backend. Nothing in that sequence requires a SurveyJS server. The repository describes the product as a UI component you embed, explicitly not a hosted form service, and states that it does not require a SurveyJS backend. The diagram in the README is labelled client-server interaction, but the server in question is yours. This is the architectural decision that matters most. Schema storage, versioning, access control and response retention are all your responsibility, and so are the failure modes that come with them: no schema migration tooling is described, so a definition you accept today is a document you must keep readable later.

Four Packages, Four Framework Entry Points

Installation is split by framework, and the package name is the only thing that changes. For React the README gives npm install survey-creator-react, for Angular npm install survey-creator-angular, for Vue.js npm install survey-creator-vue, and for plain JavaScript npm install survey-creator-js. Each has its own get-started page under surveyjs.io/survey-creator/documentation, which is where the actual component wiring lives: this README stops at the install line and links out. The documentation also points to a UI Preset Editor, described as a way to customise the Toolbox, Property Grid, tabs, actions and languages and then export the configuration as a reusable JSON preset. That preset is a second JSON artifact to manage alongside your form definitions, and it is the mechanism the README names for configuring the editor differently by role, tenant or subscription plan. If you need per-tenant editor chrome, this is the hook; the README does not describe any other.

Where the Documentation Stops and You Start

The README is a feature list, not an integration guide, and the gap is wider than the marketing suggests. Custom question types and reusable components are mentioned with a link to a documentation page, but the README gives no signature, no base class, no registration call. Theme adapters are handled the same way: a separate repository, theme-adapter-demos, is cited for mapping Survey Creator design tokens to Bootstrap, Material UI or shadcn/ui, with no token names or mapping example in this material. Localisation and right-to-left support are listed as capabilities without a config key. None of this is evidence the features are missing. It is evidence that a reader cannot evaluate the extension surface from the repository front page, and that the real cost of adoption sits in the documentation site rather than in the package. Budget for reading it before you commit to a custom question type or a per-tenant preset strategy.

The Licence Field Says NOASSERTION, and That Is the First Thing to Resolve

The repository's licence is recorded as NOASSERTION, which in practice means automated tooling could not classify it. The README does not resolve this. It states that the Form Library, a separate product in the SurveyJS family, is free and open source under MIT, and it describes Survey Creator as self-hosted and commercial in the same breath, linking to surveyjs.io/licensing. The PDF Generator is likewise described as commercial. Read together, the README distinguishes the MIT-licensed renderer from the commercially licensed builder, but it never states the Creator's own terms. This is not a legal opinion and should not be treated as one. It is a plain observation about what the repository does and does not say, and it means the licensing page is not optional reading. If your organisation has a policy against dependencies with unclassified licence metadata, that policy will block this package until someone reads the terms and records a decision.

Release Cadence and the Cost of Staying Current

The release history shows three versions published within roughly a week of each other: v3.0.4 and v2.5.41 both on 2026-09-03, then v3.0.3 on 2026-09-03 and v3.0.4 on 2026-09-10. The pattern that matters is the parallel v2.5.x line, which indicates a maintained older major alongside the current one. That is good news for teams that cannot move majors quickly, and it also means upgrade decisions are yours to schedule rather than forced by the project. There is a cost either way. A form builder sits on top of a JSON schema that you persist, so a major version bump is a question about whether previously saved definitions still load and render identically. The README claims you can version, copy and reuse form definitions, and that the same definition serves web forms, PDFs and analytics workflows. Those claims are exactly what makes a major upgrade worth testing against your stored corpus rather than against a demo. The repository README does not describe a migration guide, so treat a major bump as a task with unknown scope until you check the release notes linked from the README.

When a Schema-First Library Is the Better Fit

The clearest alternative is to skip the builder and write the JSON yourself against a schema-first rendering library, which is the same shape as the SurveyJS Form Library that this README tells you to pair with Survey Creator. The difference is who authors the definition. With a renderer alone, your engineers or your JSON templates produce the schema, and a change to a form is a change to a stored document or a config file. With Survey Creator, a non-developer drags fields, sets conditional visibility and branching, and previews the result before publication, and the schema falls out as a side effect. Choose the builder when the people defining forms are not the people writing the frontend, and when the number of forms is large enough that hand-writing schemas becomes the bottleneck. Choose the renderer alone when forms are few, stable, and reviewed like code. The builder is a larger dependency with a visual surface to localise, theme and permission, and if you do not need drag-and-drop, you are paying for an editor nobody opens.

Who Should Take This On

The fit is a product team that already owns its backend and wants form authoring inside its own UI, particularly one selling to tenants who need the editor's chrome to look like the rest of the application. The UI Preset Editor and the theme adapters are the two named mechanisms for that, and the README's mention of multi-tenant SaaS applications suggests the project expects this use. The misfit is a team that wants a free, permissively licensed builder, or one that cannot take on schema storage, versioning and response retention as first-class product concerns. Before writing integration code, do three things that this material supports: open surveyjs.io/licensing and record the actual terms for the Creator package, open the get-started page for your framework and confirm the component API matches your version, and check the release notes for the v3 major line to see what a schema-affecting upgrade looks like. If the licence terms and the framework guide both check out, the architecture is sound: the editor runs in your browser and your database keeps the JSON.

Editorial conclusion

Adopt Survey Creator if you need a white-label, self-hosted builder whose output is a JSON definition you store and render yourself, and you are prepared to read surveyjs.io/licensing before shipping. Do not adopt it if you want a free MIT-licensed builder: the README explicitly calls the Form Library MIT while the Creator's own licence is not stated there. Verify two things first: the exact terms on the licensing page, and whether your target framework has a published get-started guide under surveyjs.io/survey-creator/documentation.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. surveyjs/survey-creator on GitHub