Fontra: a font editor in the browser with a Python server behind it

Two halves: a browser client and a Python server

Fontra is described as an in-development browser-based font editor, and it consists of two main parts. The Fontra client runs in the browser and is written in JavaScript. The Fontra server runs locally or on a remote machine and is written in Python.

That split is the whole architecture, and it explains most of the project's shape. The editing surface is a web application, so the rendering and interaction code is web code, with the CodeMirror editor, the web components package and the view packages all in JavaScript. The server is the part that touches files, parses font formats, watches for changes on disk and serves the client, and it is Python with aiohttp, fonttools and the UFO tooling libraries.

The server can run locally or on a remote machine, which is what makes the multi-user deployment at the end of the roadmap possible. The project ships a plugin for that, and the roadmap lists a multi-user server deployment with database storage as implemented, delivered through the plugin, a Django based companion project and a NGINX front end. The same plugin also opens the door to a remote editor service for another font format, started with a different subcommand and a server hostname.

So the architecture supports three arrangements from one codebase: a local single user editor, a remote shared server with storage behind it, and a development mode where the server watches the client's source and rebuilds it as you type.

The licence is GPL-3.0, the project is at fontra.xyz, the default branch is main, the last push was on 2026-10-22, and the repository records no GitHub releases, so the version history lives in the changelog and in the packaged distributions.

Install the packaged app, or build both halves yourself

There are two routes, and the packaged one is much shorter.

The Fontra Pak is a Fontra distribution for macOS, Windows and Linux on x86-64. It is a self-contained server application, which means it lets you view and edit fonts in your default browser without assembling a Python and Node environment. The README points at the release section of that separate repository and at the project site as the more convenient way to get the latest build. There is also a Flatpak, and community-supported options such as a Snap package for amd64.

Building from source needs two runtimes, and the versions are stated precisely. Python 3.11 or newer, preferably from python.org, and Node.js 24 or newer. The setup then creates a virtual environment in the repository root:

python3.11 -m venv venv --prompt=fontra

After activating it, the general dependencies are installed with pip, from the requirements file and then the package itself in editable mode:

pip install -r requirements.txt
pip install -e .

The development extras add the test dependencies and the pre-commit hooks that run the formatters and linters:

pre-commit install --install-hooks

Then there are two test suites to run, one per language, which is the clearest sign that the project really is two code bases:

pytest

npm test

The Python side is built with hatchling and hatch-vcs, so the version comes from the repository's own tags rather than a hard-coded number. The JavaScript side is bundled with webpack, and the package manifest defines npm workspaces for the client core, the web components, the file system project manager and four separate view packages.

Launch it against a folder of fonts

Running the editor is a single command with a subcommand and a path, and the pattern of the subcommand is what makes the project extensible.

The filesystem subcommand points the server at a directory of font files:

fontra --launch filesystem /path/to/a/folder

The folder may contain design space files, UFO files, TrueType files or OpenType files, and the browser then opens the editor on the local address, which the README gives as port 8000.

Development mode adds the --dev flag to the launch command:

fontra --dev --launch filesystem /path/to/a/folder

That second command is the development mode, and the README explains what it does. A separate process is spawned that watches for changes to the JavaScript files and automatically bundles them into the client directory on save, and JavaScript errors report a more human-readable traceback. In other words, the development mode is a watcher plus a bundler, and it is a build tool for the client rather than a feature of the editor.

The subcommand structure is the extension point, and the Python project metadata makes it explicit. There is an entry point group for the views, with the editor, the font overview, the font info panel and the application settings each registered as a view, and another group for project managers, with the file system manager registered under the same name as the subcommand. A third command-line script handles a copy operation and a fourth a workflow command.

So the shape is a server that knows how to talk to different back ends, a client that knows how to render different views, and a registry that lets either side be extended without touching the core.

The roadmap is the specification, and it is honest about the gaps

The roadmap section is a checklist, with a green checkmark meaning the feature has been implemented, and the README is upfront that the list is not complete. It is also the single most useful document in the repository, because it is where the project's real boundaries are.

A large part of it is done. Reading and writing design space files and UFO files, with automatic reload when the files change underneath, are both implemented, as is reading TrueType and OpenType files including the variable versions, reading TTX, and writing the compiled formats, though writing those goes through an export action in the packaged application rather than a direct save. Reading and writing Glyphs files is handled by a separate plugin package, and the writing side is marked as partial.

On the text side, live text entry including slash glyph name notation, multi-line text, glyph selection, navigation of a design space through axis sliders, live interpolation, kerning display, proper text shaping, right-to-left layout, gesture scrolling and zooming, a full screen mode, and a per-glyph edit mode entered by double clicking are all implemented. Missing are the advanced character and glyph search, vertical top-to-bottom layout, and full mark positioning beyond emulation, though emulating mark-to-base, mark-to-mark, mark-to-ligature and cursive positioning is listed as done.

On the glyph side, outline editing, the pen tool, component parameters, decomposing components, first-class quadratic curves, per-glyph multi-level undo, numeric sidebearing and advance width editing, selecting segments, connecting open paths, the knife, shape and measure tools, copy and paste, creating and deleting glyphs, anchors, local guidelines are implemented. Not implemented are interactive sidebearing editing, advanced segment editing, font-level guidelines, and built-in support for non-linear interpolation.

At font level, creating a project, the cell-based overview, font info, kerning, variation axes, and both the avar and avar-2 mappings are done, while the list-based overview is not.

Two entries are questions rather than features, and they are the honest kind: whether Fontra can work as a practical GitHub gateway through the REST API, and research into database solutions.

Saving a compiled font is an export, not a save

One line in the roadmap deserves to be read twice, because it changes what a user can expect.

Direct editing and writing of TrueType and OpenType files, including the variable versions, is marked as not planned, and the note says it will still require an export step. Writing those formats is listed as implemented, but only through the export as action in the packaged application. The difference matters: you can change an outline in Fontra and export a compiled font, but you cannot open a compiled font, edit it and save it back in place.

The reason the distinction is worth spelling out is the number of formats in the checklist that support automatic reload of external changes. Design space files, UFO files, TrueType, OpenType, and the native and Glyphs formats all reload when they change on disk, and several of those are write paths as well, so for the formats the tool treats as first class the round trip is real. For compiled fonts it is not.

The flip side of that design is that the editor stays format agnostic. The core does not know what a UFO is in any deep sense, it asks a project manager, and the file system manager is one implementation of that interface alongside the remote one. The same separation appears on the client, where the editor view, the font overview, the font info panel and the settings are separate view packages that the server can choose between.

So the practical picture is a font editor that is excellent at the formats it owns and deliberately refuses to be a binary patcher for the ones it does not. If your workflow depends on opening a compiled font and saving it, that is the case to check before you plan around it.

The code layout, the pinned dependencies and the GPL

The repository listing shows a Python package and a JavaScript workspace side by side, and the separation is clean.

The Python side lives in src/, with tests in test-py/ and shared test fixtures in test-common/. The JavaScript side is in src-js/, and the package manifest lists the workspaces that make up the client: a core package, a web components package, a project manager for the file system, and four view packages for the applications settings, the editor, the font info panel and the font overview. The bundler is webpack for the client and rollup is configured as well, with TypeScript compilation through tsconfig.json.

The Python dependencies are the interesting part, because they are the font domain. fonttools with the UFO, Unicode and WOFF extras does the format work, ufo2ft compiles UFO sources into fonts, ufomerge merges them, skia-pathops provides the path boolean operations behind the subtract, intersect and exclude commands, cattrs handles the structured data, watchfiles provides the file watching, and pillow and aiohttp cover images and the server. The requirements file pins all of them to exact versions, and the project file allows newer ones, which is the usual split between a reproducible environment and a permissive install.

On the JavaScript side the editing surface is built on CodeMirror, with the autocomplete, history, language and highlight packages, and the formatting is prettier with two plugins that organise imports and sort JSON keys, which is a strong signal about how the project expects its files to be arranged.

The Python build uses hatchling with hatch-vcs, the version is dynamic, and the classifiers say it all: the development status is pre-alpha, the environment is console and web, the intended audience is developers and end users on the desktop, and the licence is GPL-3.0. That last point is worth pausing on for a font editor, because the copyleft terms of the client and the server together determine what a studio can do with a modified version.

Editorial conclusion

Adopt Fontra if you are a font designer who wants to work in a browser with a real server behind the editor, and you are comfortable with a project whose own classifiers call it pre-alpha. Do not adopt it expecting to save a TrueType file directly, because the roadmap says direct editing and writing of those formats is not planned and an export step is still required. Before you commit, read the roadmap in full, because it lists the missing features without softening them, and check that the file formats you work in are supported, since reading and writing coverage differs sharply between design space files, UFO files, Glyphs files and compiled fonts.

Frequently asked questions

Official sources

1. fontra/fontra on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README