When an agent includes a fenced code block with an explicit language tag in its markdown response, the session view tokenises the content and paints keywords, strings, numbers, comments and other syntax classes with theme-aware colours. Plain prose in unlabelled blocks is left untouched.
The agent writes a standard fenced code block with a language name on the opening fence:
```typescript
interface User {
readonly id: string
readonly name: string
}
function greet(user: User): string {
return `Hello, ${user.name}!`
}
```
Braide tokenises the block in the browser and styles each class of token with a colour that tracks the active light or dark theme, so highlighting stays consistent whichever theme you use.
If a fenced code block has no language tag, Braide deliberately leaves it as plain monospace text with no colouring. Auto-detection on short prose-like snippets is unreliable — common English words often get misidentified as keywords — so you always get the result you asked for: tag the fence to get highlighting, omit the tag to keep it plain.
```
This is plain text. No syntax highlighting is applied.
```
Note on paste auto-fencing. When you paste multi-line content into the prompt input, Braide attempts to identify the language and wraps the paste in a tagged fence before the agent sees it. By the time the message is rendered, the fence already carries a language tag. See Pasting Code.
Over 190 languages are recognised out of the box. Common ones you will encounter from agent output include:
html, css, scss, javascript, typescript, json, yaml, xmlc, cpp, rust, go, zigbash, shell, python, ruby, perl, lua, phpjava, kotlin, scala, groovy, csharp, fsharphaskell, elixir, erlang, ocaml, clojuresql, graphql, protobufdiffUse whichever language name or alias you normally would on GitHub fenced blocks — ts and typescript, py and python, sh and bash all work.
Unknown language names are silently ignored. The block still renders — just without token colouring — so you will never see a "language not supported" error in place of your code.
Keywords and function names are rendered bold; comments are italic; and deletions and additions in diff blocks are coloured red and green respectively to match the diff viewer's conventions. Token colours are theme-aware — switching between light and dark mode updates the palette instantly.
Every highlighted fenced block still shows the standard copy button in its top-right corner on hover. The text copied to the clipboard is the original source — no formatting spans end up in the copied content.
Inline code spans (single backticks inside a paragraph — `like this`) are not tokenised. They continue to render in the app's inline-code style: small monospace text on a subtle background tint. Syntax highlighting only applies to fenced blocks.
Fenced blocks tagged mermaid, likec4, or c4 are not affected by syntax highlighting. They route to the Mermaid and LikeC4 diagram renderers and display as interactive diagrams. When you toggle the Source view on a diagram block, the raw DSL renders as plain monospace text — there is no syntax highlighting for those grammars yet.