If you collaborate with a designer who works in Glyphs, or you simply want to move a project between the two apps, FontCreator's .glyphs support lets you open a Glyphs file directly and export back to .glyphs when you're done. The font editor reads and writes the .glyphs version 3 format, the same interchange format used by recent versions of Glyphs. This page walks through a clean round-trip, lists what survives the trip, and shows what you should always verify after opening or before exporting.

FontCreator on macOS with a .glyphs project open, showing the font overview and the Masters and Layers panel.

Why round-trip through .glyphs

FontCreator is a font editor that supports .glyphs, UFO, and designspace formats so you can effortlessly exchange font projects with colleagues and other software platforms. In practice that means you can pick up a teammate's Glyphs project, refine outlines or fix a feature in FontCreator, and pass the project back — or the other way around.

.glyphs is the richest of the three interchange routes because it carries design-time constructs (masters, smart components, path decorations) on top of the ordinary font data, rather than only the final geometry. UFO and designspace are the more universal fallback when the other side isn't a Glyphs-format app — see What survives, and the fallback routes below.

Open a Glyphs file in FontCreator

1. In FontCreator, choose File → Open.
2. In the file dialog, set the file-type filter to show .glyphs files (or just type the filename).
3. Select your .glyphs file and confirm.

FontCreator parses the Glyphs project — its masters, axes, glyphs, layers, anchors, kerning, and OpenType data — and presents it as a normal editable font. You now work with it exactly like any other project.

The File → Open dialog filtered to .glyphs files.

Verify right after opening

Interchange is a good moment to catch differences between how two apps model the same font, so do a quick pass before you start editing:

• Masters and axes — open the Masters and Layers panel and confirm every master and axis came across as expected.
• Smart components — check that smart components and their per-master smart layers are present. FontCreator supports smart components with full per-master smart layers nested under their owning master.
• Path decorations — confirm any corner and cap components are still attached where you expect them.
• Masks — check that mask-flagged contours and components are still flagged (see Masks across the round-trip).
• OpenType layout features and kerning — FontCreator generates explicit features from Glyphs' anchors, kerning groups, and custom feature code on open (see "How FontCreator and Glyphs model features, kerning, and anchors" below). Skim the generated features and kerning, and confirm nothing Glyphs couldn't represent was dropped.
• Glyph names and metrics — interchange often reveals naming differences between apps. Skim the glyph names and the metrics; a mismatch here is easier to fix now than after you've built features on top of it.

Tip: Run font validation after opening. FontCreator's real-time validation flags outline and interpolation issues, which is exactly what you want to catch on a freshly imported project before you invest editing time.

Export back to .glyphs (version 3)

When you're ready to hand the project back to Glyphs:

1. Choose File → Export → Glyphs Source File…. (The same Export submenu also offers UFO… and Designspace and UFOs… for the open-interchange routes.)
2. Choose a destination and filename.
3. Confirm. FontCreator writes a .glyphs version 3 file.

FontCreator provides a full round-trip with .glyphs for the everyday font data and for the design-time constructs most projects rely on — including strokes, masks, and corner and cap components, with smart-component names, axes, and per-master alternates round-tripping cleanly.

The File → Export submenu with the Glyphs source-file option highlighted.

What survives, and the fallback routes

It's easy to assume only the headline features round-trip, but the .glyphs v3 route carries the ordinary font data too — outlines, components, metrics, naming, and more — alongside FontCreator 16's design-time constructs.

Core font data

Design-time constructs (FontCreator 16)

Note on OpenType layout features. FontCreator preserves OpenType layout features through the .glyphs format, but Glyphs itself doesn't fully support every feature FontCreator can author. Anything Glyphs can't represent may be dropped once the project passes through it, so re-check your feature set after a round-trip.

If the other side of your workflow isn't a Glyphs-format app, use UFO or designspace instead. FontCreator supports both; they're the open-interchange fallback for moving glyph data and a multiple-master setup between font editors that don't speak .glyphs.

Note: For exporting actual deliverable fonts (TTF, OTF, WOFF, variable fonts) rather than an editable source, use the font-export commands instead — see Export a Font (Export Fonts Correctly).

How FontCreator and Glyphs model features, kerning, and anchors

FontCreator and Glyphs build the same fonts but model layout behavior differently, and the .glyphs round-trip is where that difference shows. In FontCreator, OpenType layout features are the working source of truth — it needs explicit features to preview them in the editor and to write them into an exported font. Glyphs keeps several of these inputs separate and only assembles the OpenType features when it exports a finished font.

So when FontCreator opens a .glyphs file, it generates the corresponding OpenType layout features up front:

• From anchors. Glyphs uses anchors internally and turns them into features only on export. FontCreator generates the anchor-based features (mark attachment and related positioning) on open, so you can preview and export them.
• From kerning. Glyphs stores kerning as left and right class groups with values. FontCreator represents kerning entirely through OpenType layout features, so those groups and values are converted into feature-based kerning on open.
• From custom features. Glyphs' custom feature code is processed and merged straight into FontCreator's internal OpenType layout features.

None of this is data loss — the layout behavior is preserved. It does mean that after opening a .glyphs file you'll see explicit OpenType layout features representing things Glyphs kept implicit, so it's worth a quick look at the generated features and kerning before you start editing.

What FontCreator writes back

The export direction mirrors this model. When FontCreator writes a .glyphs file:

• Anchors are written back as native Glyphs anchors, so anchor data round-trips as anchors in both directions.
• The OpenType layout features are decompiled to feature (.fea) code and stored in the file's feature blocks — featurePrefixes for the language systems, classes, marks, and lookups, and features for each feature tag (including stylistic-set labels).
• Kerning travels back inside that feature code, not as Glyphs' native kerning groups. Because FontCreator holds kerning as OpenType feature (GPOS) data rather than as left/right group pairs, it emits the kerning as part of the exported feature code. The kerning values are preserved, but when the project is reopened in Glyphs the kerning appears as feature code rather than in the native kerning groups it started from.

In short: anchors are the one construct that round-trips in its native form both ways; features and kerning are read from Glyphs' various inputs on the way in, and written back as .fea feature code on the way out.

Masks across the round-trip

Masks are one of FontCreator 16's headline editing features, and they're designed to survive interchange. Masks round-trip through copy/paste, undo/redo, the .glyphs format, and the FontCreator project file. Compound-path masks (rings, frames, donuts) subtract as single holes rather than full-area cut-outs, and that behavior is preserved.

The one thing to keep in mind is the asymmetry described next: masks stay as masks across a .glyphs round-trip, but they're flattened to geometry when you export an actual font.

Watch out: some features bake to geometry on export

There's an important asymmetry between exporting an editable .glyphs source and exporting a finished font.

• Exporting a .glyphs source keeps design-time constructs editable (masks stay masks, strokes stay strokes, decorations stay decorations).
• Exporting a font (TTF, OTF, CFF2, UFO) bakes some of those constructs into plain geometry. Masks are flattened automatically on export to TTF, OTF, CFF2, and UFO, and strokes and corner/cap components likewise resolve to outlines in a delivered font.

Watch out: If you open a delivered .ttf/.otf (rather than a .glyphs or .fcp source) and try to round-trip that back to .glyphs, the masks, strokes, and decorations are already gone — they were flattened when the font was built. Always round-trip from the source project, not from a compiled font, if you want the editable constructs to survive.

Frequently asked questions

Which .glyphs version does FontCreator use? FontCreator reads and writes the .glyphs version 3 format.

Do ordinary contours, components, and metrics survive? Yes. Outlines, components, metrics (advance width, LSB and RSB) including basic metric expressions, kerning, anchors, global font info, naming, and background and helper layers all round-trip through .glyphs v3.

Do my OpenType layout features survive? Mostly. FontCreator carries features through the .glyphs format, but Glyphs doesn't fully support every OpenType feature — anything it can't represent may be lost once the file passes through Glyphs. Re-check your feature set after round-tripping.

Why do I see OpenType features after opening a .glyphs file that I didn't define in Glyphs? Because FontCreator relies on explicit OpenType layout features to preview and export layout behavior, whereas Glyphs assembles features only at export. On open, FontCreator generates them from Glyphs' anchors, from its left/right kerning groups, and from any custom feature code — merging everything into its internal feature set. The behavior is preserved; it's just made explicit.

After exporting back to .glyphs, my kerning shows up as feature code instead of in Glyphs' kerning groups. Why? FontCreator stores kerning as OpenType feature (GPOS) data, so when it writes a .glyphs file it emits the kerning as part of the decompiled .fea feature code rather than as Glyphs' native left/right kerning groups. The values are preserved; only the representation differs. Anchors, by contrast, are written back as native Glyphs anchors.

Do smart components survive the round-trip? Yes. FontCreator round-trips smart-component names, axes, and per-master alternates cleanly through .glyphs version 3.

Will my masks still be masks after exporting to .glyphs? Yes — masks round-trip through the .glyphs format. They are only flattened to geometry when you export an actual font (TTF, OTF, CFF2, UFO).

My glyph names look different after opening a .glyphs file. Is that a bug? Not necessarily. Interchange between font editors commonly surfaces naming-convention differences. Review the glyph names after opening and reconcile them before building OpenType features on top.

Can I use FontCreator with someone who doesn't use Glyphs? Yes. Use UFO or designspace as the open-interchange fallback. FontCreator supports .glyphs, UFO, and designspace.

Is .glyphs support the same on Windows and macOS? FontCreator is a native font editor on both Windows and macOS, and project interchange works the same way on each: both read and write .glyphs version 3, round-trip the same data and design-time constructs, and bake the same features to geometry when you export an actual font.

What to read next

• Export a Font (Export Fonts Correctly) — building deliverable TTF/OTF/WOFF and variable fonts.
• Smart Components — authoring and editing smart components and their per-master layers.
• Path Decorations — working with corner and cap components.
• Using Masks — the non-destructive mask workflow and Decompose with Mask.