A designer hands off a polished wordmark, the developer loads the same font, and the result looks unexpectedly ordinary. The ligatures have disappeared, the swashes are missing, the numerals no longer match the layout, and a multilingual interface shows different letterforms from the approved design. The font file arrived, but the OpenType font features did not necessarily arrive as active behavior.
OpenType features are the instructions that tell a renderer how to substitute and position glyphs. They connect typography behavior with implementation details, accessibility decisions, performance review, and licensing oversight. Once you treat a feature tag as configuration rather than decoration, you can make better choices about what to enable, where to test it, and how to document it.
What OpenType Font Features Actually Do
The confusion usually starts at handoff. A designer creates the word “office” with a refined fi ligature, adjusts the spacing with kerning, and chooses old-style figures for a publication layout. The developer receives a font file and expects the same result, but the browser renders ordinary letter sequences and default numerals. Nothing is necessarily broken. The design depended on feature instructions that weren't enabled, supported, or present in the selected web font.
An OpenType feature isn't the typeface itself. It isn't the outline drawing, the font family name, or the license. It's a rule set inside the font that can alter how encoded characters become visible glyphs. A feature such as liga can substitute a glyph sequence with a ligature. A feature such as kern can adjust the position of neighboring glyphs. Other tags, including smcp and frac, can request small capitals or fraction forms.
Practical rule: A feature tag expresses a request. The font, application, renderer, language, and text context determine whether that request produces a visible result.
This explains why the same font family can look different across projects. A design application may expose a complete OpenType panel, while a web implementation may use a narrower CSS configuration. A feature can also be present in the font but unavailable for a particular script or language system. If the required lookup isn't available, the renderer may keep the default glyphs.
Four questions to ask before enabling a feature
Start with typography behavior. What should the reader see, and is the change appropriate for body copy, a heading, a table, or a wordmark? A discretionary ligature may add character to display text but reduce predictability in a form field.
Then examine implementation. Is the feature activated through a high-level property, a low-level tag, a design application panel, or a language-specific rule? The implementation must match the environment where the type will appear.
Production risk comes next. Substitutions can change text width, line breaks, alignment, and fallback behavior. Positioning rules can affect marks, joining scripts, and the appearance of small UI elements.
Finally, record licensing oversight. Desktop use and web embedding are separate licensing categories in some foundry agreements, so a feature-rich desktop file isn't automatically cleared for self-hosting. Teams comparing formats can use this practical OpenType versus TrueType guide, but the actual EULA still controls the permitted use.
Treating features as a configuration layer gives a type system a reliable operating model. Designers can specify intent, developers can implement it, QA teams can test it, and compliance teams can preserve evidence of which files and rights were used.
How the OpenType Layout System Works
A useful mental model moves from the outside of the font inward. Begin with the file, such as an .otf, .ttf, or web font format. Inside it are tables that describe outlines, metrics, character mapping, and layout behavior. OpenType was first released in 1997 by Adobe and Microsoft as a cross-platform successor to older font technologies, with support for ligatures, alternates, positional forms, and glyph substitutions. Its technical ceiling is 65,536 glyphs per font, a capacity that helped support multilingual typography and rich script coverage across Windows, macOS, and Unix/Linux environments. The Microsoft OpenType overview documents this broader format history and design.
From characters to glyphs
The text begins as Unicode characters. A font's character map identifies available glyphs, but the layout engine may then apply feature rules to change the result.
- Script and language selection: The engine identifies a script, such as
latn,cyrl, orarab, and may select a language system within that script. - Feature selection: A tag, such as
liga,kern, orlocl, identifies a group of related rules. - Lookup execution: The feature points to ordered lookups that describe the actual substitutions or positional adjustments.
- Glyph positioning: The engine places the resulting glyphs, including marks, joins, and pair spacing.
GSUB, the Glyph Substitution table, replaces one glyph with another or changes a sequence into a different sequence. The liga feature can replace the glyph sequence for f followed by i with one fi ligature glyph, if the font contains that rule. GSUB also supports single, multiple, alternate, ligature, contextual, and chained-context substitutions.
GPOS, the Glyph Positioning table, changes placement rather than identity. It can adjust a single glyph, a pair of glyphs, cursive attachment, or the position of marks attached to bases, ligatures, or other marks. It also supports contextual and chained-context positioning. This distinction matters because a spacing problem isn't solved in the same way as a glyph-shape choice.
Why the tag alone isn't enough
GSUB and GPOS use a shared structure consisting of a ScriptList, FeatureList, and LookupList, with an optional FeatureVariations table. A feature record contains lookup indices, and the same tag can lead to different behavior according to script and language system. The OpenType layout specification provides the structural model, while the GPOS documentation details positioning behavior.
That means liga doesn't define one universal visual result. One typeface may include only common Latin ligatures, while another may provide contextual rules for a script with joining behavior. Before promising a feature in a brand system, inspect the actual font and test representative text. A format guide covering file structure, licensing, and performance can help teams make that inspection part of normal asset review, as described in this font format and licensing guide.
Common and Advanced OpenType Feature Tags
Feature tags are easier to understand when grouped by purpose. The tag is a compact label, but the font designer decides which glyphs and lookups the label controls. A missing tag, incomplete lookup, or script-specific limitation can leave the text unchanged.
Everyday reading and numeric control
Standard ligatures, kerning, fractions, and numeral styles solve practical composition problems. liga commonly handles standard ligatures, while dlig requests discretionary combinations that may be more ornamental. kern controls pair spacing, although its effect depends on the font's positioning data and the renderer's feature handling.
Numeral features need particular care. onum requests old-style figures that can blend into running text, while lnum requests lining figures. tnum requests tabular widths for aligned columns, and zero can select a slashed or otherwise differentiated zero where the font provides one. The right choice depends on context, not on a universal hierarchy of “better” features.
A compact reference
| Tag | Group | Default | Behavior |
|---|---|---|---|
liga |
Reading | Often enabled by an application or environment | Standard ligature substitutions |
dlig |
Display | Usually opt-in | Discretionary ligatures |
kern |
Spacing | Often enabled by an application or environment | Pair and contextual positioning |
frac |
Numeric | Usually opt-in | Fraction construction |
numr |
Numeric | Usually opt-in | Numerator forms |
dnom |
Numeric | Usually opt-in | Denominator forms |
ordn |
Numeric | Usually opt-in | Ordinal forms |
sups |
Numeric | Usually opt-in | Superscript forms |
subs |
Numeric | Usually opt-in | Subscript forms |
smcp |
Case | Usually opt-in | Lowercase converted to small capitals |
c2sc |
Case | Usually opt-in | Capitals converted to small-cap forms |
pcap |
Case | Usually opt-in | Petite-capital forms |
onum |
Figures | Usually opt-in | Old-style figures |
lnum |
Figures | Often default | Lining figures |
tnum |
Figures | Usually opt-in | Tabular figures |
zero |
Figures | Usually opt-in | Alternate zero form |
salt |
Alternates | Usually opt-in | Individual stylistic alternates |
ss01–ss20 |
Alternates | Usually opt-in | Numbered stylistic sets |
swsh |
Display | Usually opt-in | Swash forms |
titl |
Display | Usually opt-in | Titling alternates |
calt |
Context | May be enabled by the environment | Contextual alternates |
hist |
Alternates | Usually opt-in | Historical forms |
vert |
Script | Context-dependent | Vertical glyph substitutions |
vkna |
Script | Context-dependent | Vertical kerning adjustments |
rclt |
Script | Context-dependent | Required contextual alternates |
ccmp |
Script | Context-dependent | Glyph composition and decomposition |
locl |
Language | Context-dependent | Language-specific forms |
aalt |
Alternates | Usually opt-in | Access to available alternates |
Advanced behavior needs inspection
Features such as vert, vkna, rclt, ccmp, and locl are not decorative toggles. They can support vertical writing, required contextual shaping, composition of combining sequences, or localized forms. Turning them on without representative script and language testing can produce an incomplete or unsuitable result.
ss01 through ss20 are not universal design promises. In one font, ss01 might offer a different lowercase a; in another, it might change numerals or punctuation. The same caution applies to salt, swsh, and titl. Review the font's specimen, inspect its tables, and document the intended use.
For a format-focused explanation of how OTF and TTF files relate to advanced features, see this OTF or TTF font guide. The extension doesn't tell you which tags the font includes. The font's internal tables do.
Enabling Features in CSS and Design Apps
Web implementation works best when you start with the highest-level property that expresses the intent clearly. For example, a project can use a font variant declaration for common ligatures or numeric styles, rather than placing every request into a low-level feature string. Low-level settings remain useful when a font exposes a feature that has no convenient shorthand.
A progressive approach might look like this in principle:
- Use
font-variant-ligatureswhen the goal is standard or discretionary ligature control. - Use
font-variant-numericfor lining, old-style, proportional, tabular, ordinal, numerator, denominator, or fraction behavior. - Use
font-variant-capsfor small caps and related case transformations. - Use
font-feature-settingsfor explicit tags such as"ss01" 1or"salt" 1, after confirming that the chosen font contains those features.
Low-level declarations should be scoped carefully. A stylistic set intended for a wordmark shouldn't leak into body copy. A tabular numeral rule may belong in financial data, while proportional figures may suit paragraphs. Language-specific behavior should be tied to the relevant language metadata, because locl, ccmp, and complex-script rules can depend on script and language selection.
Three gates control the result
First, the browser or rendering engine must understand the property and feature behavior. Second, the design application must expose or apply the feature correctly. Third, the selected font must contain the relevant feature and lookup coverage. If any gate fails, the text may remain in its default form.
| Feature | CSS property | Illustrator/InDesign panel | Figma support |
|---|---|---|---|
| Standard ligatures | font-variant-ligatures |
OpenType panel | Typography controls where available |
| Small caps | font-variant-caps |
OpenType panel | Typography controls where available |
| Numeric styles | font-variant-numeric |
OpenType panel | Typography controls where available |
| Stylistic sets | font-feature-settings |
OpenType panel | Typography controls where available |
| Swashes and alternates | font-feature-settings |
OpenType panel | Typography controls where available |
In Adobe applications, select text and open the OpenType controls through the relevant type panels. Look for ligatures, stylistic sets, alternates, swashes, and numeral options. Raster-based design workflows expose similar controls through character or typography panels. Affinity applications generally place these options in typography controls, while Figma exposes supported options through its text properties. The exact interface can change, so verify the current application behavior with the font in use.
Before handing off an Adobe file, check this Adobe Illustrator font installation guide. Installation alone doesn't guarantee feature access. Keep the source font, enabled tags, language settings, and output format together in the handoff record.
Browser, Platform, Accessibility, and Performance Considerations
An enabled feature changes more than appearance. It can alter glyph identity, text width, mark placement, line wrapping, and the relationship between the visual layer and the underlying character sequence. Those effects aren't universal, so teams should treat feature activation as a rendering decision that requires testing.
The web's adoption pattern shows why this belongs in production review. The HTTP Archive Web Almanac reported that roughly 61% to 62% of distinct font files on the web included at least one OpenType feature table in 2025, while well over 99% of font fetches by request volume were for fonts with OpenType features. The same 2025 Fonts chapter indicates that feature-enabled fonts are now common in real web delivery, not an edge case reserved for print.
Four risk layers
Accessibility: A visual alternate can make a letter look unfamiliar, especially in a control, label, or instructional passage. Screen readers generally operate on text content rather than the visible glyph outline, but teams still need to check copy, selection, zoom, and assistive technology workflows. Don't use a decorative substitution where recognition is essential without validating the complete experience.
Layout stability: Contextual substitutions and ligatures can change advance widths. A line may wrap differently, a button may need more room, or a heading may shift during font loading. Test the actual strings, not only isolated glyph samples.
Loading and processing: Enabling many features doesn't automatically create a measurable problem, but large fonts, broad glyph coverage, multiple weights, and complex lookup chains can increase the work involved in delivery or shaping. Subsetting requires care because removing glyphs or tables can break a feature that depends on them. This web font subsetting guide offers a useful operational frame.
Cross-platform output: Chromium, Firefox, WebKit, desktop applications, and mobile environments can expose differences in support, defaults, fallback, and shaping. Treat a result as conditional on the font and platform rather than assuming that one successful desktop proof represents every user.
Variable fonts add another policy dimension
A variable font can combine feature logic with adjustable design axes such as weight or width. A stylistic set may have been drawn with a particular range in mind, and optical sizing may change proportions or spacing as the rendering context changes. Don't assume that enabling ss01 produces the same result at every axis position.
Fallback deserves equal attention. If the web font lacks a feature or fails to load, the fallback font may have different glyph widths, numerals, or language coverage. Define acceptable fallbacks, test them under blocked or delayed font conditions, and capture screenshots of critical interfaces before release.
A recent HTTP Archive report also recorded kerning support rising from roughly 10% to 40% during the period it analyzed, which signals growing use of an advanced feature rather than a guarantee of consistent behavior. Read the 2024 Fonts chapter as evidence of adoption context, then validate your own type stack.
Common Misconceptions and Production Risks
The most expensive failures often begin with a reasonable-sounding assumption. A developer writes "liga" 1 and expects every word to change. The font contains no relevant ligature lookup, so the browser keeps the default glyph sequence. The declaration succeeded syntactically, but the intended design did not exist in that file.
Another assumption says every OpenType font includes every feature. It doesn't. Fonts expose different subsets of GSUB and GPOS behavior, and even a named feature can cover only particular scripts, languages, or character combinations. A feature inventory should therefore distinguish between a declared tag and verified lookup coverage.
Where the assumptions break
- “The tag forces the result.” It only requests the feature. Missing data or unsupported behavior can produce no visible change.
- “All browsers render the same way.” Browser, operating system, font loading state, and fallback choices can affect output.
- “A free download permits web use.” The label doesn't replace the license. Some fonts restrict embedding, redistribution, or commercial use.
- “A desktop license covers the website.” Foundry terms can separate desktop use from web use, with web rights tied to website URLs or views.
- “Visual approval is enough.” A decorative alternate can affect reading, selection, layout, or localized text after release.
Licensing exposure is concrete. In Monotype v. the-ebook-reader.com, litigation records report that Monotype sought damages connected with 80,000 infringing copies, and the court entered a $1,020,000 judgment, described as $12.75 per infringed font for 80,000 copies in the supplied public record. See the case-related licensing reference for the underlying compliance context. This article is informational only, not legal advice. Qualified counsel should review the applicable EULA and distribution model.
A Practical Governance Checklist
A reliable feature policy should live beside the font files, not only in a designer's memory. Record the approved family, file format, version, supported scripts, enabled tags, intended contexts, fallback stack, and license scope. When a foundry updates an OTF or TTF file, repeat the review because feature availability, subsetting behavior, metrics, and licensing terms can change.
Policy and implementation
- Document defaults: State which features are enabled for body text, headings, numerals, forms, and brand marks.
- Verify the font: Inspect GSUB and GPOS coverage instead of trusting a marketing specimen or tag list.
- Scope declarations: Keep decorative sets and swashes limited to approved components or display styles.
- Preserve language metadata: Test localized forms and complex scripts with the correct language settings.
- Version assets: Store the exact font files, hashes or internal version identifiers, CSS rules, and design files together.
Testing and monitoring
Run representative strings through desktop applications, browsers, mobile environments, zoom levels, delayed font loading, and fallback states. Check line wrapping, button dimensions, numeral alignment, mark placement, copy and paste, text selection, and assistive technology workflows.
Use a recurring audit process for live URLs, PDFs, images, and font packages. Font Checker Pro can scan these assets, validate feature behavior, benchmark font payload and fallback conditions, identify typefaces, and produce exportable reports for design, engineering, operations, and compliance workflows.
Licensing review
Capture the EULA with the purchased or downloaded files. Separate desktop, document embedding, web self-hosting, hosted service, client transfer, and redistribution rights. Escalate ambiguous terms to qualified legal counsel, particularly when a project uses third-party assets, variable fonts, subsetting, or multiple website URLs.
This checklist is an internal governance aid, not legal advice or a substitute for reviewing foundry EULAs, web font service agreements, or open-source license obligations with a qualified professional.
Use Font Checker Pro to audit live pages and font assets for feature behavior, rendering conditions, performance signals, and licensing evidence. Start with your highest-risk brand or multilingual pages, export the findings, and turn the results into a versioned typography policy your design, development, and compliance teams can maintain.
