Markdown’s power is its constraint: plain text with lightweight syntax. But “plain text” doesn’t mean the output should look plain. A code block should highlight like your editor. A math expression should render like a textbook. A YouTube link should embed, not display as a raw URL.

The challenge is doing this without betraying the format. The moment you require shortcodes ({{< youtube id >}}), custom directives, or tool-specific syntax, the markdown only works in your tool. It’s no longer portable. It’s no longer the format that outlasts everything.

FolderPress renders rich output from standard markdown. No syntax to learn. No plugins to install. No JavaScript shipped to readers.

#Code

Shiki — the same highlighting engine VS Code uses. 100+ languages, accurate tokenization, light and dark themes rendered at build time.

```typescript
async function syncDelta(accountId: string) {
  const cursor = await getCursor(accountId);
  const entries = await fetchDelta(cursor);
  return processBatch(entries);
}
```

Annotate the fence to highlight specific lines — useful for posts that walk through code step by step:

```typescript {3-4}
async function syncDelta(accountId: string) {
  const cursor = await getCursor(accountId);
  const entries = await fetchDelta(cursor);   // highlighted
  return processBatch(entries);               // highlighted
}
```

Shiki is expensive per render — parsing 100+ language grammars is heavier than simpler highlighters. But FolderPress renders once when content changes, then serves cached output. The cost is O(writes), not O(reads). For a blog — many reads, few writes — that’s the right tradeoff.

#Math

$inline$ and $$display$$ math via KaTeX:

The equation $E = mc^2$ changed physics.
 
$$
\int_0^\infty e^{-x^2} dx = \frac{\sqrt{\pi}}{2}
$$

KaTeX over MathJax: smaller, faster, renders to static HTML at publish time. Same server-side approach as Shiki — the server does the work, the reader gets plain HTML.

The tradeoff is LaTeX coverage. KaTeX handles the vast majority of mathematical notation but some obscure packages won’t work. For blog math — equations, integrals, matrices, summations — more than enough. If you need the full LaTeX ecosystem, you’re using a dedicated typesetting pipeline, not a markdown blog.

No opt-in. If your markdown has math, it renders. If it doesn’t, zero overhead.

#Embeds

Paste a YouTube or Twitter URL on its own line. FolderPress renders it as a native embed.

Bare URLs, not shortcodes. Shortcodes are tool-specific syntax — your markdown only works in that tool. A bare URL is portable. Paste your post into another tool and the URL is still a URL, still readable, still meaningful.

Embeds are inherently client-side — third-party iframes and scripts — so they lazy-load. Nothing fetches until the reader scrolls to them.

#The Design Decision

Every rendering feature in FolderPress follows the same rule: standard markdown syntax in, rich output out, no tool-specific extensions. The writer’s file stays portable. The reader sees quality they’d expect from a dedicated platform. The gap between those two things is what FolderPress closes — server-side, at publish time, with zero runtime cost.