Documentation

Typst 0.15.0 (June 15, 2026)

This section documents all changes to the Typst language and compiler between Typst 0.14.2 and 0.15.0. If you are migrating an existing document to Typst 0.15, make sure to check out the Migration guide. It walks you through changes you may need to make to your existing documents to ensure compatibility with Typst 0.15.

Highlights

Language

Syntax

Styling

Scripting

Library

Foundations

Model

Text

Math

Symbols

Layout

Visualize

Introspection

Data Loading

Export

Bundle

HTML

PDF

SVG

PNG

Command Line Interface

Tooling

Deprecations

Removals

Development

Migration guide

This section walks you through changes you may need to make to your existing documents to ensure compatibility with Typst 0.15.

Typst 0.15 removes definitions from the Typst standard library that were already deprecated in previous Typst versions. If you are still relying on those, also refer to the Typst 0.14 and Typst 0.13 migration guides.

Baselines

Typst now retains baseline information in more parts of the layout engine (most importantly for boxes, blocks, list items, and equations). This may lead to silent layout shifts. These are generally improvements, but if you’ve previously counter-acted bad-looking output through explicit adjustments, you may need to revisit those.

In particular, Typst will now set the baseline of a box to the baseline of its first line of content and use it to align the box with its surrounding text. This yields better-looking output out of the box.

// Typst 0.15+
Lorem #box(inset: 0.3em, stroke: 1pt)[ipsum] dolor.

// Typst 0.14 and below
Lorem #box(inset: 0.3em, stroke: 1pt)[ipsum] dolor.

File paths

If you are using Typst on Windows, you may have used backslashes in your file paths. This syntax is not supported anymore. Consistent use of forward slashes ensures your document compiles on all supported platforms.

// Typst 0.15+ ✅
#include "chapters/introduction.typ"

// Typst 0.14 and below ❌
#include "chapters\\introduction.typ"

Moreover, the Typst CLI does not support non-Unicode input paths anymore. Such paths are exceedingly rare today.

Math glyph stretching

In mathematical typesetting, glyphs frequently need to be stretched to the size of some part of an equation. This primarily applies to brackets, but also accents, arrows, and more. In Typst, this happens implicitly through matched delimiters or explicitly through the lr and stretch functions.

Typst 0.15 makes some adjustments to how ratios passed to these functions are resolved. Previously, a size of 200% passed to lr.size or stretch.size would be interpreted relative to a glyph size that was potentially already affected by display sizing. Now, ratios are always resolved relative to the base glyph size. In practice, this means that, to retain the same appearance, you may need to increase the target sizes you’ve configured for glyphs that are already larger out of the box in display style (e.g. integrals).

Math delimiters as functions

In Typst’s math mode, various symbols defined in General Symbols can be called like a function, either to be applied as an accent or to delimit body content. Typst 0.15 extends this handling to additional delimiters like chevron.l. This can change the output of existing calls, which would previously fall back to displaying the parentheses (which would rarely have produced desirable output in the case of delimiters).

// Typst 0.15+ ✅
$ chevron.l(x) $

// Typst 0.14 and below ⚠️
$ chevron.l(x) $

Math classes

The class function defines how part of an equation should be laid out (primarily the spacing around it). In Typst 0.14 and below, the class function applied recursively: If applied to a larger piece of content, all items in it would receive the class. In Typst 0.15, the class is only applied to the directly wrapped content. This is mostly a bug fix, but can lead to subtle layout changes.

Calligraphic letterforms in the default math font

With the update to New Computer Modern Math 8.1.0, the default calligraphic letterforms were changed. The previous letterforms can still be accessed by selecting stylistic set 6.

// Typst 0.15, default style.
$ R != cal(R) $

// Typst 0.15, with stylistic set 6.
// Reproduces the default style from Typst 0.14 and below.
#show math.equation: set text(stylistic-set: 6)
$ R != cal(R) $

Paragraphs, boxes, and blocks in HTML

Typst automatically collects inline-level content into paragraphs. In Typst 0.14 and below, the exact same rules were used to collect inline-level HTML elements (e.g. a <span>) into Typst paragraphs, which in turn result in <p> elements. This had the unfortunate effect that even use of the low-level typed HTML API could result in <p> elements appearing automatically. Consider the example below:

#html.div({
  html.span[Hello]
  html.div[World]
})

Where Typst 0.14 would insert an unexpected additional <p> element, Typst 0.15 yields the expected result:

<!-- Typst 0.14 and below ⚠️ -->
<div>
  <p><span>Hello</span></p>
  <div>World</div>
</div>

<!-- Typst 0.15+ ✅ -->
<div>
  <span>Hello</span>
  <div>World</div>
</div>

This change in output is achieved through a few new rules for how paragraphs are collected in HTML export. Previously, Typst would always categorize elements into either inline-level or block-level. It would then force inline-level elements into a paragraph whenever at least one block-level element was present in the same flow of content. In Typst 0.15, elements can instead be considered inline-level, block-level, or neutral:

Neutral elements don’t force adjacent inline-level content into paragraphs. They can co-exist with inline-level content in a mixed flow. This ensures that usage of the typed HTML API does not result in extraneous paragraphs.

Meanwhile, Typst elements that are block-level out of the box (e.g. heading) now explicitly use a block in their default show rule to ensure that they still force adjacent inline-level elements into paragraphs. This ensures consistency in paragraph grouping across paged and HTML export. Package authors should also explicitly use blocks when creating HTML components that Typst should consider block-level.

To make this change possible, the way boxes and blocks behave in HTML export has been adjusted: Instead of unconditionally wrapping their contents in a <span> or <div>, they now do just what is necessary to ensure their contents are considered inline- or block-level by browsers. If they contain multiple children, they still create a wrapper element, but for just a single child, they instead configure the CSS display property. And if the single child already has the appropriate display property by default, it is fully omitted. Then, the effect of the box or block is limited to influencing Typst’s paragraph grouping.

HTML script and style elements

The typed HTML functions for the HTML script and style element previously accepted arbitrary body content and then only failed during HTML serialization if the content resulted in non-textual elements. In Typst 0.15, they instead only accept strings in the first place. Note that you can also use them with raw syntax by accessing the .text field.

// Typst 0.15+ ✅
#html.style("a { color: red }")
#html.style(
  ```css
  a { color: red }
  ```.text
)

// Typst 0.14 ❌
#html.style[
  a { color: red }
]

Classes in SVG export

Typst 0.14 and below would generate the class attributes typst-frame, typst-doc, typst-group, typst-shape, and typst-text on SVG elements in SVG export. These are no longer emitted. If you are using the typst-frame class to style html.frame elements in HTML export, you’ll need to adapt your style sheet.

Variable font family names

Typst aims to unify different fonts from the same family under a single family name. To that effect, it automatically trims common style suffixes like “Bold” or “Condensed” from font family names. Instead of selecting these through the name, they should be accessed through Typst’s built-in mechanisms (such as the weight and stretch parameters).

In Typst 0.15, the additional suffixes “Variable”, “Var”, and “VF” are trimmed to unify static and variable fonts into a single family. If you’ve previously used a font with any of these suffixes in its family name, you should now omit the suffix when specifying the font.

Upcoming raw language tag changes

In the next Typst version, we will make a change to how raw language tags are parsed. Should this upcoming change have an effect on your document, the compiler will already warn you today and suggest how to adjust your document to future-proof it against the change.

Numbering fallback for the number zero

Not all numbering systems can express the number zero. In Typst 0.14 and below, those would silently fall back to Arabic numerals for 0. This behavior is deprecated in Typst 0.15. Using zero with these systems will become a hard error in the future.

Tightened validation in some functions

The array.slice function, str constructor, and text.features parameter now perform stricter validation on their inputs. If you’ve previously passed invalid or nonsensical input, you will now receive an error.

Renamed citation styles

Typst 0.15 renames some citation styles to stay aligned with upstream CSL changes. If you are relying on any of these, the compiler will warn you and suggest the new name.

Renamed symbols

Typst 0.15 also renames a few symbols in General Symbols. If you are using any of these, the compiler will warn you and suggest the new name.

Contributors

Thanks to everyone who contributed to this release!

  1. 1There are a few exceptions: Some elements like <script> are considered phrasing content by the HTML specifications, but don’t make sense in paragraphs as they default to display: none.