SnowBamboo BMF: a bitmap font generator that runs entirely in the browser

The problem it solves: font atlases without a desktop tool

SnowBamboo BMF is a free, open-source bitmap font generator for game developers and digital creators, and the positioning is stated in one sentence: create, edit and export bitmap fonts directly in your browser, with no install, no sign-up, and nothing leaving your machine.

That is a narrow promise and it is worth understanding what it replaces. The established route to a bitmap font atlas for a game is a native desktop application, and the format that most engines read is the AngelCode BMFont format. The result is a workflow where the font work happens on one machine, in a tool you install, and the output is copied into an asset pipeline somewhere else. SnowBamboo BMF moves that step into the browser, which means the tool runs on Windows, Mac, Linux and ChromeOS with the same behaviour and the same session.

The privacy claim is structural rather than a policy statement. Everything runs locally, there is no tracking and there are no uploads, and the persistence layer is IndexedDB through Dexie, with Protocol Buffers handling serialisation of the .sbf project format. A font project is a design artefact that people do not necessarily want to send to a third party, and keeping the project in the browser's own storage is the natural answer to that.

The project also targets an audience beyond new developers. The documented import list includes .sbf, .ltr and TTF, OTF, WOFF and TTC, and the .ltr route is described as Littera migration, so a project started in an older browser-based bitmap font tool can be brought over rather than redrawn.

Five distance field modes, and why the whole thing is built around a WASM port of msdfgen

The rendering half of the tool is where most of the engineering went, and it is the part that separates this from a plain bitmap font editor.

Five modes are offered: SDF, PSDF, MSDF, MTSDF and standard bitmap. A signed distance field stores, per pixel, the distance to the glyph outline, so the renderer can draw a crisp edge at any size from one texture instead of a separate bitmap per size. MSDF extends that to multiple channels so corners stay sharp rather than rounded, which is the difference people notice when a distance field font looks blobby at small sizes.

The generation is not reimplemented. msdfgen by Viktor Chlumsky is compiled to WebAssembly through Emscripten, and the project describes it as near-native distance field generation. FreeType does the font parsing, and fontkit by Devon Govett handles OpenType, TrueType, WOFF, WOFF2 and TTC, which is what covers the import list.

The parameters are exposed rather than fixed. The distance range, the angle threshold, the coloring strategy with Simple, Ink Trap and Distance options, error correction and the fill rule are all tunable, and the channel output can be White/Black, Black/White, White/Alpha or Black/Alpha. The last of those four is the practical one for engines, since an alpha-only channel is what a distance field shader usually samples.

So the promise that text stays sharp at any scale is a joint claim. The atlas is scale independent only if the engine you export to has a distance field shader, which the project states plainly in the feature list rather than leaving you to discover.

Packing is the other half of the work, and it runs in a worker pool

A font atlas is a texture, and a texture has a size limit and a memory cost, so getting the glyph rectangles packed well is the second real engineering problem.

The tool runs a worker pool over three packing algorithms, MaxRects, Guillotine and Shelf, in Auto, Fixed and Adaptive modes, with multi-page output. The three algorithms have different failure modes: Shelf is fast and simple but wastes space when glyph heights vary, Guillotine splits rectangles and can leave unusable gaps, and MaxRects generally produces tighter fits at a higher compute cost. Offering all three in a pool means the Auto mode can pick per job, and that a user with a specific atlas budget can force a particular algorithm.

The project claims packing algorithms cut memory use by 30 to 50 percent. That is a figure from the project itself and it depends entirely on the font and the target texture size, so treat it as a direction of travel rather than a number to plan a budget around.

On the rendering side the app uses React 19 with the Canvas API, and the heavy work runs in Web Workers, which is the same split as the packing: the interface stays responsive while a large atlas is being built. The application is a PWA built with a Workbox service worker, so it works offline, with in-app update prompts when a new version is deployed.

The design surface: kerning, strokes, shadows and custom glyphs

The editing features are broader than a texture packer with a glyph grid, and the details are what make it a design tool rather than a converter.

Typography covers kerning, letter spacing, baseline and per-glyph metrics. Fills can be solid, a linear or radial gradient with ten presets, or an image texture. Strokes have width, position across outer, middle and inner, and cap and join styles, and the stroke itself can take a solid, gradient or image fill. Shadows are multi-layer with every parameter adjustable. A separate section covers custom glyphs, where you drag in images for icons or special characters and the filenames map to character codes.

The canvas navigation is stated in concrete terms, which is a good sign for a tool people use daily. Space plus drag pans, Ctrl plus scroll zooms, and the zoom range runs from 25 percent to 1,000 percent. Font rendering sharpness is adjustable as well.

The workspace is tabbed, so several font projects can be open at once, and project tabs let you create or rename by double-clicking. Character input comes from a Unicode block picker and custom character sets.

The accessibility story for the app is that the exported font, not the editor, is what a screen reader or a player will meet, and the export formats decide how much metadata survives the trip. That is why the export list matters more than the feature list, and the project is explicit about it.

Exports: the AngelCode BMFont family, plus the formats engines actually ingest

The export section is where a font tool proves its value, because an atlas is only useful if the engine can read it.

The documented exports are AngelCode BMFont Text, XML, Binary and JSON, a C Header, PNG atlases and MSDF Atlas JSON. So the same design can leave the tool as a human-readable text descriptor, a structured XML file, a compact binary blob, a C array for a project that compiles its assets, a set of PNG pages, or a distance field atlas with the extra JSON that a shader needs.

Engine support is named: Unity through TextMesh Pro and the legacy path, Unreal Engine through Slate and UMG, Godot, Cocos2d and Cocos Creator, and Phaser 3 and PixiJS. The mechanism underneath is stated plainly, that the exports are in the standard BMFont format, so custom engines can read the files too. That is the important claim, because it means the output is not locked to a set of first-party integrations.

The project documentation is hosted at snowb.org/en/docs/ and the web app is at snowb.org, with a Chinese README in the repository as README_ZH.md.

One detail in the file list is worth noting for a reader choosing between this and the older tools it can import from. The .ltr import is for Littera, a browser bitmap font tool that used its own project format, and the .sbf format is this project's own, serialised with Protocol Buffers. The protobuf choice is visible in the package scripts, where a pb command regenerates the definitions through scripts/createProtocol.js.

Running it yourself: Node, Yarn and a Vite dev server on port 3000

The application is the product, and the repository is where you develop it. The prerequisites are stated as Node.js 18 or newer and the Yarn package manager.

The development setup is three steps:

git clone https://github.com/SilenceLeo/snowb-bmf.git
cd snowb-bmf
yarn install
yarn start

The dev server is Vite, and the port is 3000, so the app is at http://localhost:3000 once the start script finishes. The package.json maps both dev and start to vite, so the two names do the same thing.

The command list in the documentation is worth reading because it shows how the project is put together. The build script is tsc followed by vite build, so a type error fails the build rather than shipping. There is a lint family of four scripts, lint, lint:fix, lint:check and format, with lint:check running ESLint with a zero warning limit, and Prettier is configured with import sorting and Husky runs it as a pre-commit hook. The tests run on Vitest with React Testing Library.

The build pipeline for deployment is more layered than a single bundle, and the scripts show the pieces:

yarn build:all
yarn preview
yarn deploy

build:all is a chain of yarn build:app, yarn build:site, yarn build:merge and yarn build:sitemap, so the app bundle, the documentation site, a merge step and a sitemap generator are produced together. The deploy script uses gh-pages to publish the build directory to GitHub Pages, and a postdeploy script runs scripts/sentry.js, which releases the sourcemaps for the error reporting service. There is a separate site/ directory in the tree for the documentation site, which explains why the build has a site step at all.

Where SnowBamboo BMF is the wrong tool

The first limit is that there is no versioned artefact to depend on. The repository has no GitHub releases, the last push to the repository was on 2026-06-30, and the version lives in package.json as 1.3.0 with the private flag set. That last detail is the decisive one for anyone considering the tool as a build dependency: the package is marked private, so it is not published to a registry and the application is consumed through the site at snowb.org or from a clone. If your font generation has to run the same way on every machine and on every release, a browser application is the wrong shape for that, and the standard route of generating the atlas in a build step and committing the result is the one to keep.

The second is that the sharp-at-any-size claim is conditional on the engine. The project says it directly: scale independent if the engine supports SDF shaders. A custom engine or an older toolchain without a distance field shader gets an atlas it cannot exploit, and a standard bitmap atlas is what the standard bitmap mode is for.

The third is the shape of the feature set for a specific need. There is no scriptable API in the documentation, no headless mode and no command line export. Everything is driven through the interface, so producing forty icon fonts means forty sessions, and the batch path is a script you would write around the exported files rather than a flag you would set.

The fourth is what happens when the tool changes. A PWA with in-app update prompts and a browser storage backend means your project lives in IndexedDB in one browser profile. There is no server copy, no account and no sync, and that is a deliberate privacy property and also a real operational one: a cleared browser profile is a cleared project, and the export formats are the only backup.

The fifth is the monitoring. The package includes Sentry, the .env.example file carries a single VITE_SENTRY_DSN entry for error reporting, and the deploy script releases sourcemaps to that service after publishing. That is a normal setup for a public web app, and it is worth knowing that using the hosted app means errors are reported to the maintainers' Sentry project, which is different from the local-only claim in a strict sense, since the claim covers your font data and not your browser's error reports.

How it differs from Littera and from the AngelCode tool

Two comparisons are worth making properly, because the project's own history and its export format point at both.

The first is Littera. The .ltr import path exists because Littera was a browser-based bitmap font tool with its own project format, and migrating from it is called out as a feature. The difference in approach is that SnowBamboo BMF adds the distance field pipeline to that workflow: msdfgen compiled to WebAssembly gives SDF, PSDF, MSDF and MTSDF output from the same editor, plus a multi-mode canvas with kerning, strokes, gradients and multi-layer shadows. Littera produced bitmap atlases. The migration path is for the projects, and the addition is the distance field work.

The second is the AngelCode BMFont route, and here the difference is export format ownership rather than capability. The exports are the AngelCode BMFont Text, XML, Binary and JSON formats, and the documentation links to the AngelCode file format page. So SnowBamboo BMF is a generator that emits a format defined elsewhere, which means the output is portable to the tool that format came from and to any engine that reads it. It is not trying to replace the format, it is trying to fill a gap in how the format gets produced, which is a browser-based, distance-field-capable, privacy-preserving producer for it.

That framing also explains the engine list. Unity, Unreal, Godot, Cocos2d, Phaser and PixiJS all read BMFont, so the export targets are the union of what those engines accept, and the claim that custom engines can read the files too follows from the format being the shared denominator rather than the tool's own invention.

Editorial conclusion

SnowBamboo BMF is worth opening in a browser if you need a bitmap font atlas and would rather not install a desktop application, because the whole tool runs client side with msdfgen compiled to WebAssembly, because the export formats cover the AngelCode BMFont family that engines already read, and because the SDF and MSDF modes are built in rather than bolted on by a separate command line step. It is the wrong tool if you need a reproducible font build inside a pipeline, and it is the wrong tool if you are on an engine without a distance field shader. Before you adopt it, check three things: that the version in the repository is 1.3.0 with the last push on 2026-06-30 and no GitHub releases, so there is no versioned artefact to pin; that the package.json marks the project private, meaning the app is consumed through the site at snowb.org and not as an npm package; and that your engine can actually render a distance field, since the scale-independent text the project promises depends on the engine having an SDF shader rather than on the atlas alone.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SilenceLeo/snowb-bmf on GitHub