Typography

Introduction

Typography tokens ensure consistency, legibility, and brand flexibility across all TomTom products. They define how text appears in the UI, from large titles and guidance instructions to body text and button labels, and are optimized for automotive use.

Our system uses scalable, token-based typography that adjusts to different themes, screen sizes, and OEM requirements.

Global tokens

Typography begins at the global level, where the basic building blocks of type are defined:

• Font family — The typeface used across the UI. Example: tt_glb_font_family (e.g., Noto Sans, default font used in TomTom UI)

• Font weight — Specifies the thickness of the font. Common options include: tt_glb_font_weight_regular, tt_glb_font_weight_bold

• Font size — A global size scale that ensures consistent scaling across all typography and other UI elements (e.g., spacing, icon sizing). Example: tt_glb_size_80, tt_glb_size_16

These global tokens are neutral and brand-agnostic. They can be overridden to align with OEM identity without disrupting the structure of the system.

System tokens

System-level typography tokens give semantic meaning to type styles. These tokens group typography into meaningful categories such as:

• Display. Used for prominent, large-scale text like driving instructions.
• Title. Headers or key content lines.
• Subtitle. Secondary headings or content divisions.
• Body. Core reading content and supporting text.
• Label. Short, actionable text in buttons, chips, or UI controls.

Each system token combines the three global properties into a reusable style:

Example — tt_sys_font_display_xxl:

• Font: tt_glb_font_family
• Weight: tt_glb_font_weight_bold
• Size: tt_sys_fontSize_xl → tt_glb_size_64

Each group contains multiple size & style variations (s, m, l, etc.) to support different use cases.

Theming and scaling

Sizing is size-mode aware. Learn more about size modes here. Each size mode (Small, Medium, Large) assigns different values to the same system-level sizing tokens. The token structure remains identical across modes — only the mapped values change.

This allows:

• Centralized control of size behavior
• Predictable scaling across products and screens
• Safe adaptation without redefining component logic