You paste a tidy, indented snippet into your CMS and it turns into a run of proportional-font text. When a Quill code block loses formatting in CMS pages, the code characters are usually still there. What went missing is the presentation that Quill’s editor stylesheet supplied, or the markup that the CMS rewrote on the way in. This guide is for content editors who can reach the editor’s HTML source and a CMS preview. Start with the WYSIWYG HTML Editor and the destination’s preview, then follow the trace below to separate missing CSS from changed HTML and from a text-only paste. After that you can choose between styling the surviving classes and handing off semantic markup. All snippets are hypothetical samples, and nothing here claims to have been run against your CMS.
Table of Contents
Why a Quill code block loses formatting in CMS pages
The short answer is that the text, and even the HTML, can survive a paste while the look you saw in Quill disappears. Quill’s 2.0 upgrade guide says that code-block editing markup changed to <div> elements. Unlike <pre>, a <div> does not itself signal preformatted text. The page that displays it needs CSS to preserve indentation and to provide the font, spacing, background and overflow behavior you expect. With ordinary white-space: normal, runs of spaces collapse into one, so a two-space indent vanishes. Quill also notes that its editor requires a stylesheet even when no theme is used, which tells you the appearance lives in CSS rather than in the text.
Here is a hypothetical editor DOM for a three-line snippet, using the class names shown in a Quill issue report. Your version and configuration may differ.
<div class="ql-code-block-container">
<div class="ql-code-block">function canRetry(count, limit) {</div>
<div class="ql-code-block"> return count < limit;</div>
<div class="ql-code-block">}</div>
</div>Each line is its own block, so the lines may still stack. Nothing in that markup tells a browser to keep the two leading spaces on the second line, though. On a theme with no rule for .ql-code-block, the reader sees ordinary body text with the indentation gone. The characters are intact in the source, and only the presentation is missing.
Do not assume every export looks like this
The 2.0 statement concerns editor markup, not every export. A Quill repository issue opened on July 4, 2024 shows a syntax-highlighted editor DOM containing .ql-code-block-container and .ql-code-block divs, yet a <pre> result from getSemanticHTML(), with the highlighting spans not retained. A second issue, opened July 9, 2024, reports lost indentation and highlighting when Quill 2.0.2 editor HTML was displayed again without its original presentation context. Both are illustrated cases, not guarantees about your version, configuration or copy path.
So separate three things before you change anything: a copied selection, copied editor DOM, and your application’s own HTML export. Each can hand the CMS different markup, and the right fix depends on which one you actually have. Also check the Quill version, because the upgrade note describes a change in 2.0 and advice written for 1.x may not match.
Trace the handoff from the editor to the CMS
The prerequisites are access to the HTML source of your editor and a CMS that offers a preview. Use hypothetical or public sample code, never private code or credentials. This test uses a small block with visible indentation, so a lost indent is easy to spot:
function canRetry(count, limit) {
return count < limit;
}- In the WYSIWYG editor, create that three-line block. If syntax highlighting is available, switch it on so you can also see whether highlighting survives.
- Copy or export the content with the method your publishing workflow really uses: copying the selection, copying from the HTML source view, or your application’s export. Write that method down.
- Paste that exact HTML into the HTML Code Editor. It offers syntax highlighting, auto-closing tags and a sandboxed live preview, but it does not validate. Read the source and record whether you see Quill classes, a
<pre>,<code>elements or highlighting spans. - Avoid the beautify and minify buttons for now. Either can change whitespace, and whitespace is exactly what you are testing.
- Paste or save the same HTML into the CMS. Compare its source immediately after the paste, after save and reopen, in the preview, and on the published page.
Do not infer the exported HTML from how the visual canvas looks, because the canvas shows the editor’s own styling. Treat the HTML Code Editor as a diagnostic preview. It is not proof that your CMS will keep the same markup or load the same styles, and the site’s descriptions of its editors do not establish what markup your particular session will export. Reading the source is the only reliable way to know.
A useful outcome is a small record: for each of the four stages, which markers are present (Quill classes, <pre>, <code>, spans) and whether the two-space indent on line two is visible. The stage where a marker disappears is where the problem happens, and that tells you whom to ask: the editor’s export settings, the CMS’s import rules, or the theme’s CSS.
What to check when a Quill code block loses formatting in CMS previews
Once you know which stage changed, the symptom points to a cause. Use this table as a diagnosis aid, not as a list of certainties, because your CMS and Quill version can behave differently.
| What you see in the source | Likely cause | What to do next |
|---|---|---|
| Quill classes are still present, but indentation and font are wrong | Destination CSS is missing, or its selectors do not match. Rules scoped to .ql-editor will not match content outside that wrapper. | Inspect the element’s computed styles and add scoped rules (Handoff A below). |
| Divs and classes are gone, leaving plain paragraphs | The destination editor’s import rules or a sanitizer removed the markup. | CSS cannot restore removed markup. Try semantic <pre> and <code> (Handoff B). |
| Only plain text arrived, with no block structure | The copy route may not have provided HTML at all. | Copy from the HTML source or the application’s export, and paste into the destination’s source mode. |
A <pre> exists, but there are no colors | Highlighting spans or their styles did not travel with the export. | Accept plain monospace text, or use the site’s own highlighter if it has one. |
Notice the first two rows have opposite fixes. If the markup remains but looks wrong, the problem is styling, and you can solve it with CSS. If the markup has been removed, no stylesheet can bring it back, and you must change what you hand over or ask whoever manages the CMS to allow it. Checking the source right after paste is what separates the two, which is why the trace above compares several stages.
For background on how visual editors relate to the HTML they produce, see the guide What Is WYSIWYG Editor. It helps to remember that the visible canvas and the stored markup are different things, and only the markup travels.
Handoff A: style the surviving Quill classes
Choose this route when the CMS preserves the Quill structure and you control the destination CSS. Add a content-scoped rule set that targets the classes that survived. Here .article-body stands for a hypothetical wrapper around your post content, so replace it with whatever your theme actually uses.
.article-body .ql-code-block-container {
background: #f6f8fa;
color: #1f2328;
border-radius: 6px;
padding: 1rem;
overflow-x: auto;
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
font-size: 0.9rem;
line-height: 1.5;
}
.article-body .ql-code-block {
white-space: pre;
}The important line is white-space: pre. As MDN’s white-space reference describes, pre preserves whitespace and does not wrap lines in the ordinary way, so the indent on line two is kept and a long line scrolls through the container’s overflow-x: auto. The alternative is pre-wrap, which also preserves whitespace but allows wrapping. That value can suit narrow layouts, though wrapped code is harder to read because a wrapped line looks like a new one.
Two cautions apply. First, loading a whole editor theme onto a published page is not necessarily desirable, because it can restyle unrelated elements. Small scoped rules like the ones above are easier to reason about. Second, syntax colors need the relevant highlighting markup and its styles. A code block does not acquire colors simply because it carries a language attribute.
You can draft and preview these rules in the CSS Editor, which offers syntax highlighting, property completion and a live preview on a sample page, though it does not lint and it will not show how your theme’s cascade interacts with them. Then test in the CMS with real content: actual line breaks, indentation, a line longer than the column, and a blank line. An empty block can collapse in some markup, so check that case specifically. Because a scrolling container is a keyboard hazard when it cannot receive focus, also try reaching a long block with the keyboard in your theme.
Handoff B: send portable pre and code markup
Choose this route when you cannot add destination CSS, the Quill classes are stripped, or the content has to travel between systems. Ask for, or prepare, semantic <pre> with <code> markup. The HTML Living Standard presents that combination as a way to represent a block of computer code. It survives without Quill-specific classes, because browsers already treat <pre> as preformatted text. Here is the same hypothetical snippet as portable markup, exactly as you would paste it into a CMS source mode:
<pre><code class="language-js">function canRetry(count, limit) {
return count < limit;
}</code></pre>Notice that the literal < in the code is written as < in the markup. Code characters such as < and & must be escaped as HTML text, or the browser will try to parse them as tags or entities. If you have many characters to convert, the HTML Encoder / Decoder can encode entities so HTML can be embedded safely in text. Encoding is not sanitization, and it is not encryption. It only makes characters literal, so it does not decide what your CMS allows.
Paste this markup into the CMS’s source or HTML mode. In a visual mode, the entities may be handled again, and you could see them displayed literally. Start the code directly after the opening tags. The HTML syntax strips a newline placed immediately after the <pre> start tag, but that rule concerns <pre>, so a newline after <code> would remain and give you a blank first line.
The limits are worth stating plainly. Semantic markup does not guarantee syntax colors, and the language-js class is only a hook that a highlighter can use, not a style by itself. It also does not override a CMS that rewrites or disallows <pre> and <code>. If the class is stripped, the block still displays as monospace preformatted text, which is often an acceptable fallback.
Final checks before you publish
Run this checklist on the real destination, not just in a preview pane:
- Record which copy route you used: selection, editor DOM or application export.
- Compare the CMS source right after paste, after save and reopen, and on the published page.
- Confirm the two-space indent on line two is visible in the published page, not only in the CMS preview.
- Check a long line, a blank line and a narrow screen.
- Confirm the block scrolls or wraps as intended and does not push the page wider.
- Look at the published source to see whether classes or elements were rewritten after publishing.
Two edge cases deserve attention. Tabs render at a width determined by the browser and CSS, so a snippet indented with tabs can look different from the editor. If that matters, convert tabs to spaces before handoff. Second, if content moves between systems repeatedly, a plain, escaped <pre><code> block is the more portable choice, while a styled Quill structure is only as stable as the CSS on each destination.
If the CMS still changes the markup after all of this, the question for its administrator is specific: which elements, classes and attributes does the import or sanitizer keep? Bring the stage-by-stage record from your trace. It turns a vague complaint into a concrete request.
Frequently asked questions
Is my code lost or only unstyled when the formatting disappears?
Often only unstyled. Look at the destination’s HTML source right after paste. If the lines of code are present inside divs or a pre element, the text survived and only presentation is missing. If the source holds a single paragraph of merged text, the copy route or the CMS altered the content itself.
Can CSS bring back markup that the CMS removed?
No. CSS styles elements that exist in the page. If the destination editor or sanitizer strips the divs, classes or pre element, you need to change the handoff, for example to semantic pre and code markup, or ask the administrator which elements and attributes the CMS permits.
Should I load the full Quill theme stylesheet on the published page?
Not necessarily. A full theme can affect unrelated elements, and rules scoped to the .ql-editor wrapper will not match content that sits outside it. Small rules scoped to your own content wrapper, targeting only the code-block classes that survive, are usually easier to maintain and test.
Why does a language attribute not color my code?
A language attribute or class is only a label. Colors come from highlighting markup, such as spans, plus styles that define what those spans look like. In the July 2024 issue described above, highlighting spans were not retained in one export, so colors can vanish even when the block structure remains.
Should I choose white-space: pre or pre-wrap?
Use pre when you want exact lines with horizontal scrolling for long ones. Use pre-wrap when you want whitespace preserved but need long lines to wrap in narrow layouts. Wrapped code can be harder to read, so test with your longest realistic line before deciding.
Does the HTML Code Editor prove that my CMS will keep the markup?
No. It gives you a diagnostic view: syntax-highlighted source and a sandboxed live preview. It does not validate, and it does not reproduce your CMS’s import rules or your theme’s CSS. Use it to inspect what you are about to paste, then confirm the result inside the CMS itself.
Why do the angle brackets in my snippet disappear or render as tags?
Unescaped characters such as less-than and ampersand are parsed as HTML. Write them as < and & inside the code element, and paste into a source mode. Encoding only makes characters literal text. It is not sanitization, so it does not control what the CMS allows.
Next steps
When a Quill code block loses formatting in CMS pages, look at the HTML at each stage before changing anything. If the Quill classes survive, scope a small stylesheet with white-space: pre or pre-wrap to them and test indentation, long lines and blank lines. If the markup is stripped or the content must travel, hand off escaped <pre><code> markup and verify that the CMS keeps it. Neither route guarantees syntax colors, and CSS can never restore markup a sanitizer removed. Finish by checking the published page itself, since that is what your readers see.
Related tools and resources on HTML Editor Online:
Sources and further reading
- https://github.com/slab/quill/issues/4300
- https://github.com/slab/quill/issues/4289
- https://github.com/slab/quill/blob/main/packages/website/content/docs/customization.mdx
- https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/white-space
- https://html.spec.whatwg.org/multipage/grouping-content.html
- https://v2.quilljs.com/docs/upgrading-to-2-0
- https://html-editor-online.com/editors/html
- https://html-editor-online.com/
