Use one clear title, a short opening promise, descriptive H2 sections, restrained emphasis, compact lists, accessible images, and simple technical blocks. Preview at phone width and send a test email before publishing anything layout-sensitive.
StackDraft runs locally in your browser. No account or upload required.
Start with structure, not styling
A useful outline is the most durable formatting system. The title should describe the outcome or idea. The opening should tell readers why to continue. H2 headings should divide the argument into meaningful stages, and H3 headings should only appear when a section genuinely needs substructure.
Substack’s keyboard shortcuts can create H1, H2, and H3 blocks as you type. When importing prepared content, keep only one H1 in the source and place that text in Substack’s title field so the body begins with the introduction or first section.
- Title: specific enough to set an accurate expectation.
- Opening: context, reader problem, and promised value in a few sentences.
- H2 sections: the major questions or stages of the article.
- H3 subsections: supporting detail inside a substantial H2 section.
- Conclusion: a decision, action, or insight—not a generic recap.
Choose the right block for the job
| Element | Use it for | Avoid |
|---|---|---|
| Bold | A key phrase or label | Bold paragraphs and repeated emphasis |
| Italic | Titles, terms, or light emphasis | Long low-contrast passages |
| Bulleted list | Related items with no required order | Turning every paragraph into a bullet |
| Numbered list | A sequence or ranked set | Steps that are not actually sequential |
| Blockquote | Quoted material or a distinct pullout | Using quotes only for visual indentation |
| Inline code | Commands, filenames, variables | Long commands that need wrapping |
| Code block | Multi-line code or terminal output | Huge files and unedited logs |
| Image | Visual evidence, diagram, compact table | Essential text with no alternative |
Format for an email reading column
Email is a narrow and constrained medium. Keep paragraphs relatively short, introduce a visual pause before the reader needs one, and avoid layouts that require horizontal comparison across many columns. A desktop preview can hide problems because it gives the article more room than a phone or split-pane mail client.
Custom alignment and spacing are poor foundations for meaning. Substack’s support documentation notes that normal text, headings, and subheadings cannot be freely center- or right-aligned. Even when a special block preserves spacing, use it only when the content still makes sense in plain text.
- Put the most important information before a wide image or code example.
- Break long sections with descriptive headings, not decorative dividers alone.
- Use lists when the reader benefits from scanning, not just to add white space.
- Keep linked phrases meaningful outside their surrounding sentence.
- Assume custom colors, fonts, and spacing may change in the inbox.
Handle tables, code, math, and diagrams deliberately
Technical blocks fail when authors treat the email as a miniature documentation website. Show the smallest artifact that proves the point, then link to a complete repository, notebook, or dataset when readers need more. Every large block should earn the attention and horizontal space it consumes.
StackDraft warns about wide or long tables, very long code blocks, missing image descriptions, SVG files, and heading jumps. It also turns Mermaid diagrams into static assets. Those checks do not replace editorial judgment, but they catch mechanical problems before the draft reaches Substack.
Make the post easier to read and navigate
- Write link text that describes the destination or action.
- Add alt text that communicates the purpose of each informative image.
- Describe the takeaway from charts and image-based tables in surrounding prose.
- Keep heading levels in order so assistive navigation reflects the article outline.
- Do not depend on color alone for status, categories, or instructions.
- Expand unexplained abbreviations the first time they appear.
- Use code comments and labels when syntax alone does not communicate intent.
Run a three-view quality check
- 01
Editor view
Confirm that all content transferred, the title is not duplicated, links are attached to the right text, and image controls are available.
- 02
Web preview
Read the post from top to bottom at desktop and mobile widths. Check rhythm, heading hierarchy, captions, and any paywall transition.
- 03
Test email
Open the message in at least one desktop and one phone mail client. Click important links and inspect tables, diagrams, code, and dark-mode contrast.
Frequently asked questions
What formatting does Substack support?
The editor supports common text sizes and headings, links, bold, italic, strikethrough, inline code, lists, quotes, images, dividers, and various embedded blocks. Available controls can differ between the web and mobile editors.
Should a Substack post use H1 headings in the body?
Use the publication title as the primary heading. In a prepared Markdown source, keep one H1 for that title, copy it into Substack’s title field, and organize the body with H2 and H3 headings.
How long should paragraphs be in a Substack post?
There is no correct word count. Use paragraph breaks when the idea, speaker, time, or argumentative step changes, and remember that a paragraph appears longer on a phone than on a desktop.
Why does my test email look different from the editor?
Email clients sanitize and render HTML differently, and the reading column is often narrower. Treat the test email as the final quality check and simplify blocks that depend on precise layout.
Sources and further reading
Turn the Markdown draft into clean Substack copy.
Preview the post, catch fragile blocks, and copy the title and body separately.
Open StackDraft free