Font File Anatomy: Inside OpenType Fonts
Explore the internal structure of font files. Understand the table directory, required tables, and how TrueType and CFF fonts differ.
Key Takeaways
- • OpenType fonts are organized as collections of tables
- • 8 tables are required in every valid OpenType font
- • TrueType fonts use glyf+loca; CFF fonts use CFF/CFF2
- • Tables are located via the table directory at file start
In this article
Every OpenType font file is structured as a collection of tables, each storing a specific type of data. Understanding this structure helps you troubleshoot font issues, understand validation errors, and make informed decisions about format conversion.
The table-based architecture was inherited from the original TrueType specification and extended by Adobe and Microsoft in OpenType. Tables are identified by four-character tags (like cmap, glyf, GSUB), and their order within the file can vary — the table directory at the start of the file provides offset and length information for each table, allowing parsers to locate any table without reading the entire file sequentially.
Table Directory Structure
OpenType Font File Structure
├── Offset Subtable (12 bytes)
│ ├── sfntVersion: 0x00010000 (TrueType) or "OTTO" (CFF)
│ ├── numTables: number of tables
│ ├── searchRange, entrySelector, rangeShift (for binary search)
│
├── Table Record Array (16 bytes × numTables)
│ ├── [0] tag: "cmap", checksum, offset, length
│ ├── [1] tag: "head", checksum, offset, length
│ ├── [2] tag: "hhea", checksum, offset, length
│ └── ... (one record per table)
│
└── Table Data (varies)
├── cmap table data at recorded offset
├── head table data at recorded offset
└── ... (tables can be in any order)sfntVersion: Identifying Font Type
The four-byte sfntVersion field at the start of the offset subtable identifies what kind of outlines the font contains:
0x00010000TrueType outlines
Contains glyf + loca tables. The "1.0" version in fixed-point notation. Standard for TTF files.
"OTTO" (0x4F54544F)CFF outlines
Contains CFF or CFF2 table instead of glyf/loca. All OTF (OpenType with PostScript outlines) files use this signature.
"ttcf" (0x74746366)TrueType Collection
TTC files contain multiple fonts sharing table data. Each sub-font has its own offset subtable within the collection.
WOFF and WOFF2 files have their own signatures (wOFF and wOF2) in a separate WOFF header, but they store the original sfntVersion internally to identify the underlying font type after decompression.
The table directory enables random-access parsing of font tables without sequential file reading. Each table record stores a byte offset and length, so a parser looking for the GPOS table can jump directly to its position without reading through cmap, head, hhea, and other preceding tables. The specification requires table records to be sorted alphabetically by their four-character tag, which enables binary search through the directory. A font with 20 tables requires at most 5 comparisons to locate any specific table using binary search, compared to up to 20 sequential reads without sorted ordering. Tools like fontTools use this binary search optimization when programmatically accessing specific tables.
Each table record also stores a checksum of that table's data, calculated as the sum of all 32-bit words in the table (with the final word padded to a 4-byte boundary with zeros). The head table is special: its own checksum field is zeroed before calculating the global file checksum stored in checkSumAdjustment, which equals 0xB1B0AFBA minus the sum of all table checksums. Validation tools like OTS and Font Bakery verify both per-table checksums and the global head checksum. Any font modified after generation without recalculating checksums will fail validation—this is one of the most common issues introduced by tools that patch font binaries directly rather than using proper font APIs.
Required Tables
Every valid OpenType font must contain these 8 tables:
cmapCharacter to glyph mapping
headFont header (version, dates, flags)
hheaHorizontal header (metrics)
hmtxHorizontal metrics (advances)
maxpMaximum profile (glyph count)
nameNaming table (metadata strings)
OS/2Windows metrics and embedding
postPostScript information
Table Interdependencies
OpenType tables are not independent—they form a dependency chain that parsers must follow in order:
cmap → glyf/CFF → loca: To render a character, a text engine reads the Unicode code point from cmap to get a glyph ID, then looks up that glyph ID in loca to find its offset in the glyf table, then reads the glyph outline data from glyf.
GSUB → GDEF: The GSUB substitution table references glyph class definitions in GDEF to determine which glyphs are base characters, marks, or ligatures. GSUB lookup rules can depend on GDEF classes for contextual substitutions.
hmtx → hhea: The hmtx table stores advance widths for each glyph. The numberOfHMetrics field in hhea determines how many full records are in hmtx vs how many share the last entry—parsers must read hhea first to interpret hmtx correctly.
Outline Tables
Fonts must contain either TrueType or CFF outlines (not both):
TrueType (TTF)
glyf- Glyph outline dataloca- Glyph location indexcvt- Control value table (hints)fpgm- Font program (hints)prep- Pre-program (hints)
CFF (OTF)
CFF- Compact Font Format dataCFF2- CFF version 2 (variable)VORG- Vertical origin (CJK)
The loca Table: Glyph Location Index
The loca (index to location) table is unique to TrueType fonts — CFF fonts have no equivalent because the CFF charstring data is self-delimiting. The loca table stores an array of offsets into the glyf table, one per glyph ID plus a terminator. Two formats exist:
Short Format (indexToLocFormat = 0)
Offsets stored as 16-bit values, multiplied by 2 to get actual byte offset. Maximum glyf table size: 131,072 bytes. Used for smaller fonts.
Long Format (indexToLocFormat = 1)
Offsets stored as 32-bit values directly. No size limit. Required for fonts with glyf tables larger than 128KB — typical for CJK fonts with thousands of complex glyphs.
Advanced Tables
OpenType Layout
GSUB- Glyph substitutionGPOS- Glyph positioningGDEF- Glyph definitionBASE- Baseline
Variable Fonts
fvar- Font variationsgvar- Glyph variationsavar- Axis variationsSTAT- Style attributes
Other
kern- Legacy kerningCOLR- Color glyphsCPAL- Color paletteSVG- SVG glyphs
The OpenType Layout tables—GSUB, GPOS, and GDEF—form an interdependent subsystem for advanced typography. GSUB handles glyph substitutions: replacing one glyph or sequence with another for ligatures, small caps, stylistic alternates, or script-specific required forms. GPOS handles glyph positioning adjustments: kerning between adjacent glyphs, mark-to-base positioning for diacritics above base characters, cursive attachment for connected scripts, and contextual adjustments. Both GSUB and GPOS reference GDEF for glyph class data. GDEF classifies each glyph as a base character, ligature component, combining mark, or multi-component piece, and GSUB and GPOS lookup rules use these classifications to target appropriate glyphs during contextual matching. A font with GSUB or GPOS but lacking GDEF may experience feature failures in text engines that rely on GDEF class information during lookup application.
Variable fonts extend the standard table structure with a second axis-variation layer. The fvar table defines named design axes—weight, width, optical size, or proprietary axes identified by four-letter tags—each with minimum, default, and maximum numeric values. The gvar table stores delta arrays for every glyph, describing how each outline coordinate shifts across the design space. HVAR, VVAR, and MVAR extend variation coverage to horizontal metrics, vertical metrics, and named table values respectively. This architecture allows a single font file to replace an entire static family while remaining more compact than the combined family, since glyph outlines are shared and only the deltas between design instances are stored. Understanding this layer is essential for debugging variable font issues, where unexpected rendering at specific axis positions often traces to glyph delta data or avar normalization.
Convert with Table Preservation
Our converter maintains all font tables during format conversion.
Try Font ConverterWritten by
Sarah Mitchell
Product Designer, Font Specialist
Verified by
Marcus Rodriguez
Lead Developer
Font File Anatomy FAQs
Common questions about font table structure
