**Core feature** — always active, no configuration required.

## What it does

Every fenced code block is highlighted at build time by zfb's native class-mode highlighter. The highlighted HTML is embedded directly in the SSR output — no JavaScript is required in the browser.

## Theme

zfb emits semantic classes such as `hi-kw`, `hi-str`, `hi-num`, and `hi-com` under a `pre.hi-root` wrapper. zudo-doc maps those roles to its `--zd-syntax-*` design tokens through the `--zfb-hi-*` CSS bridge. Switching the active zudo-doc color scheme therefore recolors existing code without rebuilding the page or running a client-side highlighter.

This contract is package-owned: generated projects do not emit a renderer or theme-name block in `zfb.config.ts`.

## Supported languages

Specify the language identifier on the opening fence:

````md
```ts
const greeting: string = "hello";
```
````

Renders as:

```ts
const greeting: string = "hello";
```

Without a language identifier, the block is rendered as plain text with no highlighting.

## Emitted markup

A highlighted code block renders as:

```html
<pre class="hi-root">
  <code><span class="hi-kw">const</span> <span class="hi-var">greeting</span> …</code>
</pre>
```

When used together with the [Code Title](https://zudo-doc.takazudomodular.com/docs/markdown-features/code-title) feature, the `<pre>` is wrapped inside a `.code-block-container` div. The copy and word-wrap buttons visible in the UI are injected by client-side JavaScript and are added to every code block automatically — independent of the opt-in [Code Enrichment](https://zudo-doc.takazudomodular.com/docs/markdown-features/code-enrichment) feature, which only adds diff/line/word-highlight decorations.

## Processing order

The syntax highlighter runs in zfb's build pipeline after code-block structure has been prepared. Features that annotate a structured `<pre><code>` block run before class-mode output is finalized.

Code titles, copy and wrap controls, line and word emphasis, diff markers, tabs/code groups, Mermaid, and plain fallbacks remain separate structural features. They do not introduce a second token palette.

## Shared runtime contract

The [HtmlPreview](https://zudo-doc.takazudomodular.com/docs/components/html-preview) source panel uses the browser-time `@takazudo/zfb-md-wasm/highlight` renderer, loading the highlight-only artifact instead of the full root pipeline. The shipped highlight artifact is 1,476,740 B, compared with 3,294,286 B for the root artifact. It emits the same `pre.hi-root` / `hi-*` vocabulary and consumes the same syntax design tokens. The WASM module is loaded only when a source panel is opened (or initially rendered with `defaultOpen`); changing a color scheme or editing a syntax token recolors the existing DOM without rerunning either renderer.

## Migration from theme-name output

Current zudo-doc projects do not configure `codeHighlight.themeLight` / `themeDark`, consume `--shiki-*` variables, or install Shiki for HtmlPreview. Remove those project-owned settings and palette rules when upgrading. Existing color schemes remain compatible: every syntax role inherits an existing semantic color unless the scheme provides a syntax-specific override. See [Color — Syntax semantics](https://zudo-doc.takazudomodular.com/docs/reference/color#tier-2-semantic-tokens-syntax-semantics).

## Notes

- Document fences contain semantic classes and no inline palette colors.
- Both build-time and HtmlPreview highlighting use zfb renderers; Shiki is not a runtime or peer requirement.