When LLM Output Breaks Nested Markdown Code Blocks, and How Indented Blocks + Bookmarklets Stabilize Them

Abstract / Overview

Markdown generated by language models can break when code blocks are nested. This article compares the Markdown specification with observed behavior in chat interfaces and editors, then proposes a practical pattern designed to survive copying and reuse. The goal is operational stability, not a universal or theoretically perfect solution.

1. Introduction: What breaks, and why it matters

When asked to explain a topic in Markdown or put an answer in a code block, a model may use the same fence for both the outer document and an inner example. A parser then reads the inner closing fence as the end of the outer block. The chat interface may appear correct even when copied plain text is not.

• Nested code blocks can close unexpectedly and expose later text.
• Rendered chat output may differ from the copied text.
• Reuse in editors such as Obsidian, GitHub, or VS Code can reveal the breakage.

This discussion is based mainly on ChatGPT experiments, with behavior that can also occur in other LLM workflows. It does not claim that every renderer behaves identically.

2. Markdown code blocks: a minimal specification review

2.1 Indented code blocks

Original Markdown supports code blocks by indenting each line with four spaces (or a tab). This older form is widely supported and naturally avoids fence collisions when nested. It is less convenient to read and edit, and it does not provide a standard language label for syntax highlighting.

2.2 Fenced code blocks

CommonMark and GitHub Flavored Markdown define fenced blocks using at least three matching backticks or tildes. A language identifier may follow the opening fence. Fence lengths and delimiter choice matter when examples contain other fences.

3. Why nested blocks break: specification versus practice

The common failure is delimiter collision: an outer block and an inner example both use three backticks. The parser may treat the inner delimiter as closing the outer block, so following paragraphs become ordinary text or are rendered as code. Language tags and post-processing can make the visible result harder to predict.

Markdown has several related dialects, including CommonMark, GFM, Pandoc, and editor-specific renderers. Edge cases involving nesting, blockquotes, inline code, and post-processors can differ. Content that looks right in one interface may not survive copy and paste into another.

4. LLM-specific behavior

In the experiments, models strongly favored triple backticks, appeared less reliable at maintaining an outer fence across long output, and sometimes produced different results in rendered UI and copied plain text. Training patterns and service-side formatting may both contribute. The specification alone does not explain all observed failures.

5. Experiments: six patterns

Six nested-code patterns were compared in ChatGPT, then selected outputs were copied into Obsidian. The first three did not produce usable results in the observed runs. Cases four through six were taken forward; cases four and five remained the most practical candidates.

To display a calculation in JavaScript:

    let sum = 10 + 20;
    console.log("The total is " + sum + ".");

The inner sample is indented instead of opened with another fence.

Cases 4–6 were pasted into Obsidian for a second check. The original study also recorded ChatGPT renderings and paste results; this clean static edition summarizes those observations without embedding service-interface screenshots.

6. Result: a rule based on indented style

Rule for nested code blocks
Inside a fenced code block, represent inner code using four-space indentation. Do not put a fenced code block inside another fenced code block.

This is a practical rule, not a guarantee. Some environments may need adjustment. The original workflow used a bookmarklet to reinsert the instruction when preparing a prompt; applying it only when needed avoids imposing it on every response.

7. Why indentation was selected

Tildes can be a useful alternative because they differ from the backticks commonly used by models and can retain language identifiers. However, in the observed workflow, getting a model to consistently preserve the alternate fence was less reliable. A later processing step may also normalize delimiters.

Indented blocks are widely supported and less exposed to fence collisions or normalization. Their trade-offs are reduced readability in raw text and no standard language annotation. In controlled environments, tildes remain a reasonable option to test.

8. Bookmarklet and practical limits

A browser bookmarklet can prepend the indentation rule to the current prompt before requesting Markdown output. This allows the instruction to be applied on demand. The exact interaction depends on the chat interface, which may change; browser extensions could implement a similar workflow.

• LLM output is not perfectly reproducible, even with carefully designed instructions.
• The rule may lose influence over a long conversation, so reapplying it can help.
• Short answers that do not wrap the entire response in a code block may avoid the nested-fence problem.
• Adapt the pattern to the destination renderer and verify critical output after pasting.

9. Summary

• Nested code-block failures arise from the interaction of delimiter rules, renderer differences, and generated output.
• Using four-space indentation for inner code was the most stable practical pattern in the observed experiments.
• Triple tildes can work in controlled workflows, but should be checked in the intended renderer.

References

1. CommonMark Project, CommonMark Specification 0.31.2.
2. GitHub, GitHub Flavored Markdown Spec.
3. John Gruber, Markdown: Syntax.