# Tagify: a tags input component for vanilla JS, React, Vue and Angular

> Tagify turns an input or textarea element into a tags component with a whitelist, suggestions and validation. It ships as a plain script from a CDN or as the @yaireo/tagify package, and the README is explicit about what it does not do.

**yairEO/tagify** — 🔖 lightweight, efficient Tags input component in Vanilla JS / React / Angular / Vue

- Repository: https://github.com/yairEO/tagify
- Website: https://yaireo.github.io/tagify/
- Stars: 3,894 · Forks: 448
- Language: HTML
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/yaireo-tagify

## What Tagify replaces, and who ends up using it

A plain text input collects one string. The moment a form needs several values in one field, whether they are email recipients, categories or labels, the usual answer is a comma-separated string plus parsing code on the server. Tagify takes that same input element and turns it into a component where each value becomes a visible tag the user can delete, edit or reorder, while the underlying element still submits the collected values with the form.

The README frames the target audience through the four builds it publishes: vanilla JavaScript, React, Vue and Angular. That matters because the same component has to work in a plain HTML page with no build step and inside a framework app with a bundler. The repository's package.json lists peer dependencies including prop-types, which points at the React wrapper, and the exports map exposes ./react, ./vue and ./dist/tagify.esm.js as separate entry points. If your stack is none of those four, Tagify is the wrong shape of dependency.

## How the whitelist, the underlying input and the dropdown fit together

The mechanism is narrower than the feature list suggests. You pass an existing input or textarea element and a settings object. The whitelist array is optional, and the README says that without it you can allow any tag to be added with no suggestions offered. Each whitelist entry can be a string, a number or an object, and an object must carry a value property. That value is what gets written into the original input element, so when the form is submitted the server receives the values, not the display text.

When the display text needs to differ from the submitted value, the tagTextProp setting is the documented switch. Suggestions can be rendered at the full width of the component or next to the typed text at the caret, and the README notes that suggestion aliases can be set so fuzzy searching matches a wider set of input. Pasting multiple values separated by commas or newlines creates several tags at once. Tags can also be created through a regex delimiter or by pressing Enter.

The original element is not replaced by a hidden field you have to wire up yourself. That is the design decision worth noticing: the component decorates the element rather than abstracting it away, which keeps server-side form handling unchanged.

## Installing Tagify from the CDN or as an npm package

The README gives two installation paths. The CDN path places a script and a stylesheet before any code that uses Tagify, and the component then becomes available globally. The npm path installs the package under the @yaireo/tagify name.

```bash
npm i @yaireo/tagify --save
```

After the install, the README's basic example imports the default export and constructs the component on a selected input element. The whitelist below mixes strings and numbers, which the README explicitly says is supported.

```js
import Tagify from '@yaireo/tagify'

var inputElem = document.querySelector('input')
var tagify = new Tagify(inputElem, {
  whitelist: ['foo', 'bar', 'and baz', 0, 1, 2]
})
```

One step is easy to miss and the README flags it as important: the stylesheet must be included. The CSS lives at @yaireo/tagify/dist/tagify.css and the SCSS source at @yaireo/tagify/src/tagify.scss. A component that renders correctly but looks unstyled is almost always a missing stylesheet, not a bug in the configuration.

For CDN users the README shows the jsDelivr URLs for the script and the stylesheet, and notes that a specific version can be requested with the @ syntax, giving unpkg.com/@yaireo/tagify@3.1.0 as the example. Pinning a version this way avoids picking up a newer release on every page load.

## Where Tagify stops: accessibility, licence metadata and thin spots

The feature list strikes through ARIA accessibility support and adds a parenthetical explanation: the component is too generic for any meaningful ARIA. That is an unusually direct admission, and it should shape your decision. If the tags field is part of a workflow that must pass an accessibility audit, Tagify does not claim to solve that for you, and the README does not describe a keyboard or screen-reader contract you can rely on.

The licence metadata is inconsistent. The repository reports NOASSERTION, while package.json declares "license": "MIT" and the README badge links to a description of the MIT License. NOASSERTION from repository metadata usually means the licence could not be identified automatically, so the declaration in package.json is the more specific signal, but the LICENSE file at the repository root is the text that actually governs. Read it before you ship.

The README also does not document rollback or downgrade steps. Releases exist, with v4.38.0 published on 2026-06-27, v4.37.1 on 2026-04-19 and v4.37.0 on 2026-04-03, but the README gives no migration notes between them. If you pin a version and later need to move, you are reading the release history yourself.

Build requirements are another boundary. package.json sets engines to node >=22 and pnpm >=10, and the build script runs gulp build. That applies to building the project from source, not to consuming the published dist files, but anyone forking to patch behaviour inherits those versions.

## Tagify compared with a native select and a hand-rolled input

The closest alternative is not another tags library but the elements already in the browser. A multiple select gives you several values in one field with built-in keyboard behaviour and no JavaScript, but it renders as a list box, not as removable chips inside the text flow, and it cannot accept a value the user types that is not already an option. Tagify's whitelist is optional precisely because free typing is a supported mode, so a select cannot cover the same ground.

The other alternative is writing the component yourself: a text input, a keydown handler, an array of values, and a hidden input to submit them. That is genuinely small for a single field, and it gives you full control over markup and accessibility, which is the area Tagify declines to address. The cost appears later, when you need paste handling, duplicate detection, editable tags, drag and sort, an AJAX-backed suggestion list or per-tag validation. The README documents all of those as existing features, and each one is a separate problem to solve if you build your own.

A middle path is to keep your own markup and use Tagify only for the value handling, but the README's DOM templates section is where that becomes real: the wrapper, tag, dropdown, dropdown item, dropdown header and dropdown footer templates can each be overridden.

## Maintenance, upgrades and what the repository state tells you

The repository is not archived, and the last push was on 2026-09-08. Three releases landed between April and June 2026, which is a cadence you can plan around. The README does not publish a support window, a deprecation policy or upgrade instructions between major versions, so the practical upgrade cost is: read the release notes for the version you are moving to, and check whether any setting or method you use is mentioned.

Because the package publishes both dist and src directories, a consumer can read the same source the maintainer builds from. That helps when a documented behaviour and the shipped code disagree, but it also means the surface you depend on includes whatever the settings object accepts, and the README's settings section is the only contract.

On licence, the MIT declaration in package.json and the README badge point one way while repository metadata says NOASSERTION. MIT is permissive and imposes no source-disclosure obligation, but this is a factual discrepancy in the project's own files, not a legal question I can settle. If your organisation requires an audited licence, the LICENSE file is the document to check, and the discrepancy is worth raising upstream.

## Conclusion

Adopt Tagify when you need a tags field in a plain HTML form or a React, Vue or Angular app and you want the original input element to keep carrying the submitted value. Skip it if you need meaningful ARIA semantics, since the README states the component is too generic for that, or if your build cannot ship the stylesheet alongside the script. Before committing, verify the licence text in the LICENSE file, because the repository metadata reports NOASSERTION while package.json declares MIT, and confirm that the dist files in the published package match the version you pin.

## FAQ

### What is Tagify used for?

It transforms an input field or textarea into a tags component, so several values can be entered, edited and removed in one field while the original element still submits those values with the form. The README lists whitelists, suggestions, validation, drag and sort, and mixed text-and-tags content among its features.

### How do I use Tagify in a page?

Import the default export from @yaireo/tagify, select the input element, and construct a new Tagify instance with a settings object such as a whitelist array. The README states that the stylesheet at @yaireo/tagify/dist/tagify.css must also be included, otherwise the component renders unstyled.

### Why do I get "tagify is not defined"?

The README's CDN instructions say to place the script tag before any other code that uses Tagify, because the global is only available after that script loads. If you installed the npm package instead, the default export is imported as a module rather than read from a global.

### What can I use instead of Tagify?

A multiple select element covers several values in one field with native keyboard behaviour but cannot accept a typed value that is not an option, while Tagify's whitelist is optional so free typing is allowed. Writing the component yourself is viable for a single field, though paste handling, duplicate detection and drag and sort each become separate work that the README documents as built in.

### Is Tagify easy to learn?

The basic setup is a single constructor call with an optional whitelist, which the README presents as the most basic example. The learning cost sits in the settings, methods, events and hooks sections, and in overriding the DOM templates if you need different markup.

## Sources

- [Issues](https://github.com/yairEO/tagify/issues)
- [Project website](https://yaireo.github.io/tagify/)
- [README](https://github.com/yairEO/tagify/blob/master/README.md)
- [Releases](https://github.com/yairEO/tagify/releases)
- [yairEO/tagify on GitHub](https://github.com/yairEO/tagify)

---

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