How to truetype hinting vs modern subpixel rendering
- Step 1Identify the rasteriser your audience uses — Windows 10+ → DirectWrite (outline-first, hints largely ignored). Windows 7/8 → GDI + ClearType (hints used for grid-fitting). macOS/iOS → CoreText (never used TrueType bytecode hints). Linux → FreeType, where behaviour swings on whether the bytecode interpreter is enabled at build time.
- Step 2Pull the numbers from your analytics — The only audience where stripping is risky is GDI-era Windows. Check your OS/browser breakdown for the Windows 7/8 share. Below ~1% it's noise; above ~5% it's a real cohort to think about.
- Step 3Strip a representative weight — Run one body-text weight through the [Hinting Stripper](/font-tools/hinting-stripper). Note the `Saved %` chip — that's your upper-bound bandwidth win for this face. Remember the output is a raw TTF; re-compress with [TTF → WOFF2](/font-tools/ttf-to-woff2).
- Step 4Side-by-side at the sizes that matter — Render the same paragraph hinted vs. unhinted at 11px, 13px, and 16px on each target OS. Above ~14px or on any 2x display, the two are visually identical. Differences, if any, surface only at 10–12px on GDI.
- Step 5Decide per audience, not per font — If your traffic is modern Windows + Mac + mobile, strip across the board. If a legacy Windows cohort matters (enterprise intranets, industrial kiosks), serve them the hinted source and everyone else the stripped build.
- Step 6Document the decision — Record the analytics threshold you used and the date. "Stripped because Win7/8 GDI < 1% as of 2026-06" is a defensible note that ends the recurring debate.
What each rasteriser does with TrueType hints
Behaviour for TrueType (glyf) outlines. CFF/OTF fonts hint differently and are not affected by stripping fpgm/prep/cvt at all.
| Platform / engine | Reads TrueType hints? | Practical effect of stripping |
|---|---|---|
| Windows 10/11 — DirectWrite | Largely ignores (outline-first) | No visible change at normal sizes |
| Windows 7/8 — GDI + ClearType | Yes — uses hints + gasp for grid-fitting | Slightly softer at 10–12px; the one cohort that notices |
| macOS / iOS — CoreText | No — never used TT bytecode hints | Zero difference; always safe to strip |
| Linux — FreeType (bytecode on) | Yes, if interpreter compiled in | Distro-dependent; modern distros lean on the autohinter |
| Linux — FreeType (autohint) | Ignores embedded hints, hints on the fly | No difference — FreeType wasn't using them anyway |
| Android | FreeType-based, autohint-leaning | No meaningful difference at typical UI sizes |
Why hinting mattered then and not now
The variable that changed is pixels-per-glyph, driven by display density.
| Factor | 1995 | 2026 |
|---|---|---|
| Typical display density | 75–96 DPI | 150–300+ DPI (retina/HiDPI common) |
| Pixels in a 12px lowercase 'e' | A handful — every pixel decisive | 4× or more on a 2x display — grid-fitting noise |
| Dominant Windows engine | GDI (hint-driven) | DirectWrite (outline-first) |
| Antialiasing | Crude or none — hints essential | Sub-pixel / grayscale smoothing everywhere |
| Net role of embedded hints | Load-bearing for legibility | Mostly redundant; safe to remove for modern audiences |
Cookbook
Concrete decision scenarios. The tool itself has no per-renderer setting — it always removes the same seven tables — so 'strip or not' is an audience call you make before running it.
Consumer SaaS, modern traffic
ExampleAnalytics: 62% Windows 10/11, 24% macOS, 11% iOS/Android, <0.4% Windows 7/8. The hint-reading cohort is statistical noise.
Decision: STRIP across all weights. Reason: DirectWrite + CoreText + mobile ignore hints. Action: hinting-stripper → ttf-to-woff2 for every weight. Outcome: 5–20% smaller fonts, no perceptible change for 99.6% of users.
Internal enterprise app on Windows 7 fleet
ExampleA line-of-business intranet still pinned to Windows 7 + IE/legacy Edge. GDI is the only renderer in play.
Decision: KEEP hinting. Reason: GDI + ClearType use fpgm/prep/cvt + gasp for grid-fitting. Action: ship the original hinted font. Note: stripping would soften 11px UI labels for this exact audience.
Apple-only product (Mac + iOS app web views)
ExampleCoreText has never consumed TrueType bytecode hints, so the hint tables are pure overhead here.
Decision: STRIP — unconditionally safe. Reason: CoreText ignores TT hints on every macOS/iOS version. Action: hinting-stripper → ttf-to-woff2. Outcome: smaller payload, pixel-identical rendering.
Mixed audience, split delivery
Example8% Windows 7/8 but the rest modern. You can serve both without compromising either.
Decision: SPLIT. - Modern UA → stripped + WOFF2 (small, identical rendering) - Win7/8 UA → original hinted font (crisp at small sizes) Mechanism: @font-face with conditional src, or server UA sniff. Keep the hinted master in the repo to build both.
Validating 'invisible' before committing
ExampleDon't trust the theory blind — prove it with a pixel diff at the sizes you actually use.
1. Render a paragraph hinted vs unhinted at 11/13/16px per OS. 2. Screenshot at the same DPR; diff the images. 3. Expect: identical at 16px and on 2x; tiny deltas only at 10-12px on Win7 GDI. 4. If the diff is empty for your audience → strip with confidence.
Edge cases and what actually happens
Every row below was probed against the live API. Some documented requirements (alphabetical axis order, numerical tuple order) are not actually enforced in practice — useful to know if you've been blaming the wrong thing for a 400.
'macOS uses hints sometimes' — it doesn't
By designCoreText (macOS/iOS) has never executed TrueType bytecode hints. Apple rasterises from outlines with its own antialiasing. Stripping hints from fonts served to Apple users is always pixel-safe — there is no version or setting where this regresses.
ClearType implies hints are still essential
Context-dependentClearType is subpixel antialiasing, and the GDI path uses hints + gasp to grid-fit before antialiasing. But ClearType-via-DirectWrite (Windows 10+) is outline-first and doesn't depend on embedded hints the way GDI did. 'ClearType' alone doesn't tell you whether hints matter — the engine underneath (GDI vs DirectWrite) does.
FreeType results vary by distro
ExpectedFreeType can run the embedded bytecode interpreter, the autohinter, or neither, depending on build flags. Modern distros usually favour the autohinter, which ignores embedded hints and grid-fits on the fly — so stripping changes nothing. On a rare interpreter-on build at small sizes, you might see a hair of difference.
Stripping an OTF expecting a rendering change
PreservedOTF/CFF fonts don't carry fpgm/prep/cvt — their hints live in the CFF charstrings, which CoreType/DirectWrite/FreeType handle via the PostScript hinter. The Hinting Stripper finds nothing to remove on a CFF font and leaves rendering identical everywhere.
Expecting better rendering after stripping
ExpectedStripping never improves rendering — at best it's invisible (modern engines), at worst slightly softer (GDI small sizes). The win is file size, not crispness. If your goal is sharper text on legacy Windows, you want more hinting, not less.
High-DPI assumption on a 1x monitor
Context-dependentPlenty of users still run 1x (96 DPI) external monitors even on Windows 10/11. DirectWrite still renders cleanly there without embedded hints, but it's the closest modern case to where hints once mattered. Test at 1x if a large share of your audience uses standard-DPI displays.
Print / PDF rendering
Not applicableHints are a screen-rasterisation concept. PDF/print pipelines render outlines at high device resolution and ignore screen hints entirely, so stripping has no effect on printed or PDF-embedded text.
Server-side rendering of text to images
Depends on libraryIf you rasterise text to PNG server-side (e.g. social cards), the library's engine decides. Headless Chromium uses its platform engine; a raw FreeType pipeline depends on its hinting mode. For large card text the difference is nil; for tiny captions, test.
Frequently asked questions
Does Apple ever respect TrueType hints?
No. CoreText on macOS and iOS has never executed TrueType bytecode hints; it rasterises from outlines with Apple's own antialiasing. Stripping hints for an Apple audience is always safe.
What does ClearType actually do?
ClearType is Microsoft's subpixel antialiasing. On the old GDI path it works together with hints and gasp to grid-fit glyphs first. On DirectWrite (Windows 10+) it's outline-first and doesn't lean on embedded hints, so the same 'ClearType' label means different things on different engine generations.
Are TrueType hints ever still useful in 2026?
Yes, narrowly: 10–12px text on Windows 7/8 GDI, plus a few niche cases (bitmap-emulating display fonts, pixel-exact technical diagrams). For mainstream consumer web typography on modern engines, they're effectively dead.
Will stripping make text look better anywhere?
No. Best case it's invisible; worst case (GDI small sizes) slightly softer. The benefit is purely file size — typically 5–20% — not visual quality.
Does DirectWrite completely ignore hints?
Largely. DirectWrite is outline-first and doesn't depend on embedded TrueType hints for legibility the way GDI did. In practice, stripping produces no visible change for DirectWrite users at normal reading sizes.
What about Linux and FreeType?
It depends on the build. FreeType can use the bytecode interpreter, the autohinter, or neither. Modern distros usually autohint, ignoring embedded hints — so stripping changes nothing for those users.
Do I lose hinting differently for OTF vs TTF?
OTF/CFF fonts aren't affected: their hints live in CFF charstrings, not in fpgm/prep/cvt . The Hinting Stripper only removes TrueType-specific tables, so it's a no-op on a CFF font's rendering.
How big is the visual difference, really?
On a 2x/retina display or at 14px+: none you can see. At 10–12px on Windows 7 GDI: a faint loss of grid-snapped crispness, visible mainly in a side-by-side pixel diff, not in normal use.
Should I decide per font or per audience?
Per audience. The renderer your users run, not the font itself, determines whether hints are read. The tool always removes the same seven tables, so the only real decision is who you're serving.
How do I confirm it's safe before shipping?
Render hinted vs unhinted at 11/13/16px on each target OS, screenshot at matched DPR, and diff. If the diff is empty for your audience's renderers, strip with confidence.
Does this tool let me tune behaviour per renderer?
No. The Hinting Stripper has no options — it removes fpgm, prep, cvt , gasp, hdmx, VDMX, and LTSH every time. 'Strip or keep' is the only lever, and it's an audience decision made before you run it.
Where can I see which hint tables my font carries?
Inspect it with font-format-identifier or font-metadata-extractor to see the table inventory, so you know how much there is to gain before stripping.
Privacy first
Every JAD Font tool runs entirely in your browser using opentype.js and the wawoff2 WASM Brotli encoder. Your fonts never leave your device — verified by zero outbound network requests during processing.