Markdown Indentation: Nested Lists, Paragraphs, and Code
Fix Markdown indentation with examples for nested bullets, numbered lists, continuation paragraphs, and fenced code. Avoid accidental code blocks.
To indent a Markdown sublist, align its marker beneath the first character of the parent item's text. For - Parent, that means two spaces. For 1. Parent, it means three. Indentation controls document structure, so adding spaces to a normal paragraph can have a very different effect from changing a Word paragraph's visual indent.
Start with this example in the Markdown viewer:
- Project documents
- Installation guide
- Release notes
- Review checklist
The installation guide and release notes should appear beneath the project-documents item. The review checklist should remain at the outer level.
Count From the Parent Item's Content
For ordinary list items written with one space after the marker, use this alignment guide:
| Parent begins with | Characters before its text | Sublist indentation |
|---|---|---|
- | 2 | 2 spaces |
1. | 3 | 3 spaces |
12. | 4 | 4 spaces |
100. | 5 | 5 spaces |
This is why a blanket rule such as "always use two spaces" fails for numbered lists. GitHub's nested-list documentation illustrates alignment relative to the parent content, including longer numeric markers.
1. Prepare the release
- Confirm the version number.
- Update the changelog.
2. Publish the documentation
The nested markers have three leading spaces. If they begin at the left margin, they start a separate list instead of belonging to the first numbered step.
When working with an older Markdown processor, preview the file in that processor too. The examples here target CommonMark-style parsing and GitHub Markdown; legacy implementations can differ in how they recognize nested blocks.
Add a Paragraph Within a List Item
A longer explanation does not need its own bullet. Leave a blank line, then align the new paragraph beneath the item's text:
1. Review the installation guide.
Confirm that a new reader can complete the setup without
opening an internal document.
2. Approve the release notes.
The explanatory paragraph belongs to step one. Its two source lines flow together, unless you add an explicit line break.
Leaving out the three spaces can end the numbered list and turn the explanation into a normal paragraph. That can also cause the following list to restart numbering in some editing workflows.
The same pattern works with bullets:
- Installation guide
Include prerequisites, setup commands, and a verification step.
- Release notes
Use a separate paragraph when the explanation contains several sentences. Use a sublist when it contains distinct items that readers should scan individually.
Put Code Inside a Numbered Step
Fenced code makes the boundary of a command example visible. Indent the opening fence, contents, and closing fence to keep the block inside the list item:
1. Check the installed version.
```sh
node --version
```
Record the result in the review notes.
2. Run the project checks.
Here the fence starts under the first letter of Check. The paragraph after the fence uses the same alignment, so it stays within the first step too.
If the next numbered step becomes part of the code block, inspect the closing fence. If the code appears outside the list, inspect the fence's leading spaces. See the code-block guide for language labels and literal backticks.
Why Four Spaces Can Turn Text Into Code
At the document's outer level, after a blank line, four spaces before a line can create an indented code block:
An ordinary paragraph.
This line is displayed as code.
This is intentional Markdown syntax, not a broken indent control. The CommonMark indented-code-block reference explains the role of indentation and block boundaries.
An indented line immediately following ordinary paragraph text has different parsing constraints, so inserting spaces is not a dependable way to create a visual paragraph indent. Inside lists, the required spaces are relative to the containing item as well.
For a quotation, use a blockquote. For ordinary prose that needs a first-line indent in a final report, keep the Markdown as a normal paragraph and apply the paragraph formatting in Word after export. Those choices preserve the intended meaning of the content.
Prefer Spaces When Debugging
Tabs can occupy several display columns, and different editors can display them at different widths. If a list looks aligned in the source but renders incorrectly, show whitespace in your editor and replace leading tabs with the required number of spaces.
Do not replace tabs inside code examples indiscriminately. There, whitespace may be part of the example itself. Limit the cleanup to the Markdown markers and continuation indentation that determine the surrounding list structure.
Avoid using repeated nonbreaking-space entities to imitate a nested list. That may make text look shifted in one preview while leaving the underlying document as unrelated paragraphs.
Verify the Structure Before Word Export
Review one representative section containing a parent item, a sublist, a second paragraph, and a fenced code block. In the Markdown to HTML converter, a real nested list is contained within its parent list item; a visual offset alone does not establish that relationship.
Then use the Markdown to Word converter and open the DOCX. Check that numbering continues as intended and commands remain associated with their steps. Word's list styles may use different visual spacing from the browser, so assess both the hierarchy and the final document's appearance before sharing it.