Type fundamentals

Text is the primary way of communicating within GitLab. A thoughtful use of semantics and visual hierarchy can provide consistency and clarity to aid in comprehension and action.


GitLab Sans, based on Inter, is used for most user interface (UI) elements, with system fonts used as a back-up. GitLab Mono, based on JetBrains Mono, is used for code-related elements, for example, code blocks, branch names, commit IDs, and pipeline IDs. The fonts are available to download in this package.

The decision to use custom typefaces supports a consistent core experience for users, regardless of their device. A finer control of font size, variable weight, and other attributes like disambiguation enable greater optimization of usability and polish.

The typefaces were chosen because:

  • Tall x-height that improves legibility at small sizes and readability of mixed- and lower-case text.
  • Features that include character disambiguation and OpenType Font Variations.
  • Balanced and complementary pairing that supports the GitLab brand expression.
  • Open source.

Sans serif font stack

font-family: 'GitLab Sans', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Noto Sans',
  Ubuntu, Cantarell, 'Helvetica Neue', sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji',
  'Segoe UI Symbol', 'Noto Color Emoji';

Monospace font stack

font-family: 'GitLab Mono', 'Menlo', 'DejaVu Sans Mono', 'Liberation Mono', 'Consolas',
  'Ubuntu Mono', 'Courier New', 'andale mono', 'lucida console', monospace;

Type scales

GitLab utilizes two type scales: dynamic and fixed.

  • The dynamic scale is used for any UI text within GitLab. The 500800 options rely on the viewport width to dynamically change size between the min and max.
  • The fixed scale is used for Markdown (user generated content). Sizes match the min of the dynamic scale.
Variable Dynamic scale Fixed scale Use
Min Max
$size-text-100 12px 12px 12px Meta text, small labels
$size-text-200 13px 13px 13px Level 6 headings
$size-text-300 14px 14px 14px Level 5 headings, body text, input labels, help text
$size-text-400 16px 16px 16px Level 4 headings, large body text
$size-text-500 18px 20px 18px Level 3 headings
$size-text-600 21px 25px 21px Level 2 headings
$size-text-700 24px 30px 24px Level 1 headings, limited to one per page (see Semantics).
$size-text-800 28px 36px 28px A display option that can be applied to a level 1 heading to increase its prominence. This can be useful for a learning path or feature promotion. Limited to one per page.

Note that in implementation the variables use rem values (relative units) instead of pixels (absolute units), so that text respects browser settings for size and scale.

Contextual adjustments

By default, heading levels are mapped to the dynamic scale. However, in some cases, visual hierarchy can be established aside from semantics. For example:

  • In an alert, its container already has sectioning affordances like color, spacing, and iconography. Because of this, a level 2 heading in the alert doesn't need the same emphasis as a level 2 heading for a content section elsewhere on the page.
  • Similarly, in a card, the properties of the card itself indicate a section. Because of this, a level 3 heading may not require the same sectioning effect as a level 3 heading in body content.

When in doubt, use the scale by default, consider the full page context, and reference existing patterns.

Provide more guidelines and examples of scale overrides. Create an issue
Add UI kit links after #1527 has been completed. Create an issue

Font weight

GitLab uses contrasting font weights to support visual hierarchy within the application. Generally, three weights are used by default: 400, 600, and 700.

Value Use
400 Body copy and data tables
600 Headings and specific UI elements, such as an input label
700 Inline with 400 for content of greater importance

Text color

There are a number of text colors defined in GitLab. Color choice depends on the location and purpose of the text.

Category Variable Example
Primary $gray-900 Main titles and body
Secondary $gray-500 Accompanying help text or menu subtitles
Tertiary $gray-400 Placeholder or disabled


  • Every page should have a level 1 (h1) heading. It can be visually hidden if the context of the page is clear for all users, but it must be present in the DOM.
  • Headings should not skip levels, with the following exceptions:
    • When an alert, or other messaging component, gets inserted before the main page content. These components are designed to use a level 2 (h2) heading.
    • When a heading is used to identify a region, like navigation. Generally, a level 2 (h2) heading is used.
    • In user-generated Markdown content a user can order headings as they like. The visual appearance of a heading is the only guide provided for choosing the correct hierarchy.
  • Styles correspond with semantics by default, for example, an h3 is larger and has more visual weight than an h4.

Last updated at: