@formio/angular: rendering JSON schema forms in an Angular app

One component turns a schema into a rendered form

The library is described as a dynamic JSON powered form rendering library for Angular, and the mechanism is a single custom element. You provide a JSON schema to a formio Angular component, and the form is rendered dynamically inside the front end application, which is what allows forms to be built from JSON schemas rather than from Angular templates.

The simplest usage points the component at a URL:

<formio src="https://examples.form.io/example"></formio>

Or you pass the JSON form directly, which is what a self-contained application would do:

<formio
  [form]='{
    "title": "My Test Form",
    "components": [
        {
            "type": "textfield",
            "input": true,
            "tableView": true,
            "inputType": "text",
            "inputMask": "",
            "label": "First Name",
            "key": "firstName",
            "placeholder": "Enter your first name",
            "prefix": "",
            "suffix": "",
            "multiple": false,
            "defaultValue": "",
            "protected": false,
            "unique": false,
            "persistent": true,
            "validate": {
                "required": true,
                "minLength": 2,
                "maxLength": 10,
                "pattern": "",
                "custom": "",
                "customPrivate": false
            },
            "conditional": {
                "show": "",
                "when": null,
                "eq": ""
            }
        },

Reading that schema tells you a lot about the dialect. The structure is a components array, each element has a type such as textfield or button, and each carries a long list of presentation and behaviour keys. Validation is a nested object with required, minLength, maxLength, pattern and a slot for custom rules, and conditionals are a nested show, when and eq structure. A button element carries action, disableOnInvalid and theme.

This is not JSON Schema. It is Form.io's own component format, and that is the most important thing to know before you start: a schema you author elsewhere will not import here.

Installation, the Angular version problem, and the compatibility matrix

Installation is the ordinary npm or yarn add of the package name @formio/angular, and the readme also gives the pinned variants for older Angular versions:

    npm install --save @formio/angular

    npm install --save @formio/angular@a18

The version handling is the part that needs attention. The readme says the library supports many different Angular versions and points to a compatibility matrix for using the library with the correct version of Angular, and it also notes that the Form.io open source repositories are maintained with all latest versions available via NPM.

The usage section shows a slightly different command, which installs the release candidate of the Angular package together with the JavaScript library it depends on:

npm install --save @formio/angular@rc @formio/js

The @rc tag on the package and the @formio/js dependency together are a signal about the current state of the release line. The package manifest in the repository shows version 11.0.6, while the readme refers to the release candidate channel, and the repository has no GitHub releases at all, so the npm tags are the version history to look at rather than the release page.

The manifest is also where the Angular dependency becomes concrete. The development dependencies are all pinned to a catalog entry called catalog:angular21, so the toolchain is built around Angular 21, with the Angular CLI, compiler, core, forms, router and platform-browser packages all coming from that catalog. The devDependencies also include @formio/core at 2.8.3 and @formio/js at 5.6.0, which is where the actual rendering engine lives.

The last push was on 2026-09-18, so the code is being worked on.

Registering the module and choosing a framework template

The module is imported into an Angular application in the ordinary NgModule way, alongside the browser and common modules:

import { FormioModule } from '@formio/angular';
@NgModule({
  imports: [BrowserModule, CommonModule, FormioModule],
  declarations: [AppComponent],
  bootstrap: [AppComponent],
})
export class AppModule {}

The rendering template is a separate decision, and it is a runtime choice rather than a build time one. By default the library uses Bootstrap 5 as the template and rendering CSS framework, and the readme explains that this can be changed by adding different templates into your application and using them as follows:

npm install --save @formio/bootstrap@rc

import { Formio } from '@formio/angular';
import bootstrap4 from '@formio/bootstrap/bootstrap4';
(Formio as any).use(bootstrap4);

The Formio class is imported from the Angular package and a use method registers the template globally. Note the cast to any in the example, which tells you the registration API is not strongly typed, and that the template choice is global to the application rather than per component. A single application can therefore only use one template package at a time.

That design has a clear motivation. The template is a set of CSS and markup that determines how every field type looks, and shipping the framework as a separate package means the Angular library does not hard code a visual language. A team with an existing Bootstrap 4 design can keep it, and a team with no Bootstrap at all can supply their own template package.

Six libraries in one package, and what each one is for

The readme describes the Angular package as a combination of multiple libraries that enable rapid serverless application development, and then lists six of them, each with its own wiki page.

The Form Renderer is the form renderer in Angular, which is the component you have already seen. The Form Builder is the form builder in Angular, which is the design time counterpart where someone lays out the form rather than filling it in. The Form Manager is the form management application used to manage forms.

The remaining three are about the data around the form. Authentication allows an easy way to provide Form.io authentication into your application. Resource is a way to include the resources within your application with full CRUDI support, where CRUDI stands for Create, Read, Update, Delete and Index. The Data Table, also called the Grid, renders data within a table format, which includes pagination and sorting.

That is a much larger scope than a form renderer, and it is the reason the package pulls in @formio/js, since the underlying JavaScript library is what implements the component types, the builder and the resource behaviour. The Angular package is the Angular shaped surface over that engine.

The scope is also why the serverless framing appears. A form renderer on its own saves you writing the markup. Adding a builder, a form manager, authentication, a resource API and a grid means an application can be a form system with no separate backend to write, which is a genuine saving for a small team and a real constraint for a large one that already has a data layer.

Where a schema-driven form stops being the right answer

There is a clear limit, and it is the same limit that every schema driven UI has.

The library earns its keep when the form structure varies, and that means it varies at runtime, usually per customer, per tenant, or per form type stored in a database. If your application has eight known forms that your own team writes and reviews, a schema runtime is overhead: you gain the ability to change a form without a deploy and lose the compile time checking and the refactoring tools that a typed component library gives you.

The second limit is the dialect. The component format shown in the readme is Form.io's own, with its own key names and its own nesting conventions, and a lot of the schema is presentational keys such as tableView, inputMask, prefix and suffix. Porting a schema from another tool is a translation job, and porting to another tool later is a translation job in the other direction. The readme does not document a converter.

The third is the surface area of the dependency. The rendering engine lives in @formio/js and the templates in separate packages, and the Angular library itself is the orchestration. A team that wants a single text field with a label has taken on a schema format, a template system, a builder, a resource layer and an authentication integration.

The readme is also candid that the library can build very complex forms which include e-signatures, columns, panels, field conditionals and validation requirements, and the list goes on. That is a description of capability, and it is also a description of the number of things that can go wrong when a form is misconfigured in production rather than caught by a compiler.

Editorial conclusion

Adopt @formio/angular if you are building an Angular application that needs forms whose structure comes from configuration rather than from a template, and you want a builder, a form manager and a resource API delivered with the renderer. Do not adopt it if your forms are a fixed set written by your own developers, since a JSON schema runtime is the wrong tool for a handful of known inputs, and check the schema dialect before you commit, because the component format is Form.io's own rather than plain JSON Schema. Before you commit, render one of the example forms from the readme, confirm the framework template package you want is available, and read the compatibility matrix so the Angular version you install matches your app.

Frequently asked questions

Official sources

1. formio/angular on GitHub
2. Issues
3. License: MIT
4. Project website
5. README