patorjk/figlet.js: FIGfont rendering in JavaScript, in the browser and in Node

What figlet.js solves, and who it is actually for

FIGlet renders plain text as large ASCII art using font files that follow the FIGfont spec. The original figlet is a C program. figlet.js is a JavaScript implementation of the same spec, written in TypeScript and compiled to JavaScript, and the README states that it works both in the browser and with Node. It was written to power the TAAG application at patorjk.com, and the README links to that site as a live demonstration.

That origin explains the audience. This is for people who need FIGlet output inside a program rather than in a shell: a build script that prints a banner, a web page that renders a heading as ASCII art, a chat bot that replies in block letters. If you only want to type figlet Hello in a terminal, this package is the wrong layer. The README frames the project as a driver, and the API it documents is a function call that returns a string.

The package is published on npm as figlet, and package.json declares bin pointing at ./bin/index.js, so a command line entry does exist. The README, however, never shows it being used. Anyone evaluating this as a drop-in replacement for the C tool should treat that gap as unresolved rather than assume parity.

How the FIGfont spec is implemented across Node and browser builds

The package ships separate entry points rather than one bundle with runtime checks. package.json defines main as ./dist/node-figlet.cjs, module and browser as ./dist/figlet.mjs, and an exports map with distinct browser and node conditions, each with its own import and require paths plus matching type declarations. So bundlers resolving the browser condition get the browser build, while Node gets node-figlet, which is the variant that can read font files from disk.

Fonts live in the repository in the fonts/ and importable-fonts/ directories. The README does not spell out how the Node build discovers a font by name, but the split between a node-figlet entry point and a plain figlet entry point is the visible mechanism: the browser build cannot read the filesystem, so it must import fonts as modules, which is what importable-fonts/ is for. If you are targeting the browser, that directory is where you should look first.

The rendering pipeline is the standard FIGlet one. A FIGfont file describes each character as a block of rows, plus smushing rules that decide how adjacent characters overlap. figlet.js exposes two layout knobs, horizontalLayout and verticalLayout, each accepting default, full, fitted, controlled smushing, or universal smushing. The README's kerning example prints the word Kerning in the Standard font three times, with default, fitted, and full spacing, and the three blocks visibly differ in width while the letterforms stay the same. That is the whole point of the option: it changes spacing, not glyphs. The README also notes that most fonts do not support vertical kerning, so verticalLayout is often inert in practice.

Installing figlet.js and rendering your first banner

The README gives the install as a single npm command. The package is ESM-first, with type set to module in package.json, so the import form is the one the README shows first.

npm install figlet

The quick start uses an async function and awaits the text method, which returns a promise resolving to the generated art.

import figlet from "figlet";

async function doStuff() {
  const text = await figlet.text("Hello World!!");
  console.log(text);
}

doStuff();

Run that and you should see the Hello World block from the README, rendered in the Standard font, which is the documented default for the font option. A callback form also exists for older code, using require and passing a function that receives err and data.

Once the default works, the interesting step is passing an options object. The README's example renders Boo! in the Ghost font with width 80 and whitespaceBreak enabled, and shows the resulting ghost-shaped output.

console.log(
  figlet.textSync("Boo!", {
    font: "Ghost",
    horizontalLayout: "default",
    verticalLayout: "default",
    width: 80,
    whitespaceBreak: true,
  })
);

The width option caps the output at a character count, and whitespaceBreak, which defaults to false, makes the library try to break on whitespace when that cap is hit. The README points to examples/front-end/index.htm for a working demonstration of both.

Where figlet.js is the wrong tool

The width and whitespaceBreak options are the weakest part of the documented API. width defaults to undefined, meaning no wrapping at all, and whitespaceBreak only takes effect alongside width. Nothing in the README describes what happens when a single word is longer than the width and there is no whitespace to break on, and nothing describes how the wrap interacts with verticalLayout smushing across the break. If you are rendering user-supplied strings at a fixed terminal width, that is the case you need to test yourself rather than trust.

The font resolution story is the second gap. The README documents the font option as a string naming a FIGlet font, but it never states where the Node build looks for those files or what happens when the name does not match one. The repository contains fonts/ and importable-fonts/, which suggests the answer differs by target, but the README is silent on the lookup path and on the error you get for an unknown font. In a browser bundle that silence is sharper, because a missing font cannot be fixed by dropping a file into a directory.

Finally, this is a rendering library, not a terminal program. Anyone arriving from the C figlet expecting FIGLET_FONTDIR, a font list command, or the standard system font directory will not find those documented here. The README's entire surface is the JavaScript API.

figlet.js compared with running the figlet binary

The obvious alternative is the original figlet program, which is what most people mean when they search for how to install figlet on Linux. The difference is not output quality, since both target the FIGfont spec, but where the work happens. The C tool is a process you invoke, configured by environment variables and a font directory on the machine. figlet.js is a module you import, configured by an options object, with fonts shipped inside the repository.

That distinction decides the choice. If your banner is generated once during a build or a shell session, spawning the binary is simpler and keeps the font directory under system control. If the banner is generated at request time by a Node service, or in a browser tab where no process can be spawned, the binary is not an option at all and figlet.js is. The package's exports map makes this concrete: the browser condition resolves to dist/figlet.mjs, a build with no filesystem access, while the node condition resolves to node-figlet, which is the variant that can load font files.

For Python users, pyfiglet is the comparable library, and it is a separate project with its own font handling. The search data shows people asking how to use pyfiglet in Python, which is a different question with a different answer: pyfiglet is imported as a Python module, and nothing in this repository applies to it.

Maintenance, licence, and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-19. The most recent release listed is v1.11.4 on 2026-07-29, preceded by v1.11.3 on 2026-07-21 and v1.11.0 on 2026-03-10. The cadence is steady, and the patch releases in July suggest bug fixes rather than a rewrite.

The licence is MIT, declared in package.json and present as LICENSE.txt at the repository root. For most consumers that means the usual permissive terms, with the copyright notice and permission notice retained. I am not a lawyer and this is not legal advice; the practical point is that MIT imposes no copyleft obligation on your own code, and the fonts bundled in fonts/ and importable-fonts/ may carry their own notices, which is worth checking if you redistribute them.

The upgrade cost is dominated by the dual-build layout. Because package.json maps separate browser and node entry points, with import and require variants and per-variant type declarations, a change to that map can break a bundler resolution even when the rendering code is untouched. If you pin the package, pin it exactly and re-read the exports map after any minor bump, since v1.11.0 to v1.11.4 happened inside five months.

Editorial conclusion

Adopt figlet.js when you need FIGlet output inside a JavaScript or TypeScript program, in Node or in a browser bundle, and you are willing to load font files yourself. Skip it if you want the classic figlet command line with its system font directory: this package is a library first, and the README documents a bin entry but no CLI usage. Before committing, verify how fonts resolve in your target runtime, and check the actual output of your chosen font at your target width, because layout options change spacing rather than the glyphs themselves.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. patorjk/figlet.js on GitHub
4. README
5. Releases