Why do code blocks break when converting a ChatGPT export?

Almost always because the converter uses a fixed three-backtick fence. If the code itself contains three backticks, the block ends early and the rest of the note is misparsed. The fence has to be longer than the longest backtick run inside it.

Why is there < in my exported code?

The converter HTML-escaped the source and never reversed it. Code going into a Markdown file should not be HTML-escaped at all.

Will my syntax highlighting still work?

It works if the language tag on the fence survives the conversion. It is present in the export, so losing it is a converter defect rather than a limitation.

Here, yes — maths is handled as its own block type and bypasses Markdown escaping, so the symbols reach your notes intact.

Code is where a converter earns its trust.

Guide · Fidelity

You converted the export, opened a conversation with a useful snippet in it, and the code is ruined: the fence has swallowed the prose beneath it, the language tag is gone so nothing is highlighted, or < is sitting in the middle of your source where a < used to be.

This is the most common complaint about every export converter, and it is not bad luck. It comes from a small number of specific mistakes, all of which are avoidable and none of which are visible until you look at the file.

1. Nested backticks break the fence

The failure that ruins the most files. If a code block contains a triple backtick — and any conversation about Markdown, documentation, or prompts will contain several — then wrapping it in another triple backtick ends the block early. Everything after it spills out and the rest of the note is misparsed.

The fix is in the spec and takes one line of code: the outer fence must be longer than the longest run of backticks inside it. Four backticks around a block containing three. Most converters use a hard-coded three and hope.

2. The language tag gets dropped

The export knows the block was Python. If the converter does not carry that through to the fence, your vault renders a grey box of undifferentiated text and every snippet you saved becomes marginally harder to read forever.

It is metadata that already exists in the source. Losing it is careless rather than difficult.

3. HTML entities leak into source code

<, > and & appearing inside a code block mean the converter ran your source through an HTML escape and then never unescaped it, or escaped it twice. The result is code that no longer compiles and that you have to repair by hand, line by line, years later, without knowing which characters were changed.

Escaping has to be applied at the point of output and only where it belongs — never to the contents of a code block that is going into a Markdown file.

4. Math gets Markdown-escaped

LaTeX is full of characters Markdown wants to interpret: underscores, asterisks, backslashes. Escape them and the maths stops rendering; do not escape them and the surrounding prose breaks instead.

The answer is to treat maths as its own block type that bypasses inline escaping entirely, rather than as text that happens to have symbols in it.

5. Tables and nested lists flatten

A table becomes rows of text separated by pipes; a nested list loses a level of indentation and reads as one flat list. Both come from re-serialising structured content as prose and hoping the shape survives.

Both are also easy to check, which is the real point of this page.

How this converter is held to it

Every one of the above is a case in a fixture suite: nested fences, multi-language code, tables containing pipe characters, block and inline maths, deep blockquotes, raw HTML inside a message, headings at every level, nested lists, unicode and right-to-left text, emoji.

Each fixture has a checked-in expected output, compared byte for byte on every change. If a change to the renderer would alter so much as a space in any of them, it does not ship. That is not a claim about care; it is a test that either passes or does not.

The same fixtures back the sample output shown on the home page, so what you see there is generated by the same code that will run on your file.

Checking your own output

Whatever tool you end up using, the check takes two minutes. Find a conversation you know contained a code block with backticks in it, and one with a table. Open the converted note in a plain text editor rather than a preview pane — a preview will often hide exactly the damage you are looking for — and see whether the fence closes where it should and whether the pipes are still doing their job.

If you would rather just see it work: the free inspection below will convert the ten most recent conversations from your own export so you can look at real output from your own file before deciding anything.

Questions

4 answered

Why do code blocks break when converting a ChatGPT export?: Almost always because the converter uses a fixed three-backtick fence. If the code itself contains three backticks, the block ends early and the rest of the note is misparsed. The fence has to be longer than the longest backtick run inside it.
Why is there < in my exported code?: The converter HTML-escaped the source and never reversed it. Code going into a Markdown file should not be HTML-escaped at all.
Will my syntax highlighting still work?: It works if the language tag on the fence survives the conversion. It is present in the export, so losing it is a converter defect rather than a limitation.
Does LaTeX survive?: Here, yes — maths is handled as its own block type and bypasses Markdown escaping, so the symbols reach your notes intact.