html-tags

html-tags exports two plain JSON arrays — the complete set of standard HTML tags and the subset of void (self-closing) elements — sourced directly from the WHATWG HTML spec rather than hand-maintained. A companion build script scrapes the spec’s indices and syntax pages with cheerio, regenerating both the JSON data files and their matching TypeScript literal-union types on every run, so the list and its types can never drift out of sync with each other or with the standard.

Because the package ships zero runtime dependencies and the data as static JSON imported via import assertions, it works identically in Node, browsers, and bundlers with no parsing logic to trust — just an array to check membership or iterate against. It’s small enough to embed in linters, sanitizers, static-site generators, or any tool that needs a canonical answer to “what counts as an HTML tag” without vendoring the spec itself.

What You Get

• Full array of standard HTML tag names (html-tags.json, the package’s default export)
• Separate array of void/self-closing tag names (html-tags-void.json, exported as voidHtmlTags)
• Auto-generated TypeScript union types (HtmlTags, VoidHtmlTags) that stay in lockstep with the data
• A build script (scripts/build.js) that re-scrapes the live WHATWG spec with cheerio to refresh both lists

Common Use Cases

• HTML sanitizer allowlisting - a security-focused sanitizer checks incoming tag names against the standard list to strip anything non-conformant
• Static-site generator validation - a markdown/MDX pipeline validates that custom components don’t collide with reserved HTML tag names
• Linter rule authoring - a lint rule for JSX or templates needs a canonical set of void elements to flag invalid self-closing syntax
• Editor tag autocompletion - a lightweight code editor extension autocompletes HTML tag names without bundling a full parser or spec dataset

Under The Hood

Architecture The published package is intentionally flat: index.js re-exports two static JSON files (html-tags.json, html-tags-void.json) using native with {type: 'json'} import assertions, with no runtime logic of its own. The data-generation path is a separate concern, isolated in scripts/build.js, which fetches and caches the WHATWG spec’s indices and syntax pages, parses them with cheerio, and writes both the JSON arrays and their matching .d.ts type-declaration files. This separation means consumers only ever touch the trivial re-export layer, while the scraping complexity is fully decoupled and run on a schedule rather than at install or import time.

Tech Stack The package itself declares zero runtime dependencies — pure ESM ("type": "module") targeting Node 20.10+. The build tooling uses cheerio for HTML parsing of the fetched spec pages and a simple filesystem cache (10-hour TTL) to avoid re-fetching on every run. Testing runs on ava, linting on xo, and the package exports both index.d.ts types and per-dataset .d.ts files generated as literal string-union types.

Code Quality Test coverage is minimal but purposeful: test.js asserts both exported arrays are arrays within a sane length range (10-1000 items), acting as a sanity check on the scraper’s output rather than exhaustive validation. There’s no complex control flow to test — the actual logic under scrutiny lives in the build script, which is guarded by xo’s linting rather than unit tests. Naming and typing are consistent throughout, and CI (via .github/workflows) presumably re-runs the scrape periodically to catch spec changes.

What Makes It Unique Unlike most “list of HTML tags” gists or hardcoded arrays that quietly go stale, this package’s data is regenerated by parsing the actual WHATWG specification pages rather than being manually transcribed once and forgotten. Combining that with auto-generated TypeScript literal-union types (rather than a generic string[]) gives consumers compile-time tag validation for free, which hand-maintained alternatives typically don’t offer.