Article Layout: From Markdown to a Ready-to-Publish Draft

Why Layout Keeps Getting Reworked

Rich-text editors are designed for "write it quickly". Their strength is paragraphs and basic bold; their weakness is hierarchy. In a long article with five sections, manually bolding subheadings, inserting dividers and changing font sizes by hand almost always ends with inconsistent heading sizes, quote blocks that do not match, and list indentation that drifts. And these problems are rarely noticed while writing — they surface on the read-through before publishing.

The other source of rework is writing the content separately from the layout. Many people draft in an external document and then paste it into the editor and reflow it. The paste is where things get eaten: inline-code shading, code-block backgrounds and multi-level list indentation all lose something at that step, and have to be rebuilt by hand.

Splitting "writing" and "laying out" into two steps, and automating the layout step, is the most direct fix for both. While writing, think only about content and structure; the visual layout comes out of a fixed pipeline.

Basic Conventions for Drafting in Markdown

Use only two heading levels

Markdown supports six heading levels, but only two are actually useful in a long article. Leave the first for the article title (the editor fills that in itself, so do not repeat it in the body), and use the second for section headings. When you need to go deeper, start a line with a bolded lead-in instead of a third level — readers scroll on phones, and more than two heading levels makes the structure feel heavy.

## Section heading

Body paragraph.

### Do not write this level. Use: **a bolded lead-in**

Lists, quotes and dividers

Unordered lists use -, ordered lists use 1. — do not mix the two inside one list. Quotes use >, suited to pull quotes or notes that need to stand apart from the body. Separate sections with ---.

Code blocks and inline code

Inline code is wrapped in backticks; code blocks use triple backticks. Rich-text editors have limited support for code blocks — after conversion you usually keep only the background colour and the monospace font, and syntax highlighting does not always survive. If an article contains a lot of code, screenshot it separately and paste the image: that is more reliable than relying on conversion.

Converting Markdown to a Rich-Text Draft

Once the draft is written, paste the whole Markdown document into the input of Markdown to Styled HTML — the layout renders on the right in real time. The flow is five steps:

1. 1Paste the Markdown into the left-hand input; the preview on the right renders the layout immediately.
2. 2Pick a colour theme from the settings — there are eight: green, blue, grey, black, brown, purple, red and orange — and a body font size, one of three: small, medium, large.
3. 3If you need an image, change the canvas to 1800x3200 or 2400x3200, or set a custom width and height.
4. 4Click copy, then paste into the article editor. Use "keep formatting" rather than plain text.
5. 5Check the images and code blocks one by one — those are the only two element types that occasionally need manual adjustment afterwards.

Only the last of the five steps is a judgement call; the other four are repeatable actions. The value shows up on long articles: the longer the piece, the more rework is saved.

Choosing Theme, Font Size and Canvas Size

The theme sets the colours of the body, headings and quote blocks. Choose it by account positioning rather than personal taste: low-saturation grey and blue suit knowledge accounts, orange and red suit lifestyle accounts. If an account publishes one consistent type of content, fixing one theme is more recognisable than changing it every piece. The eight themes swap their colours as a group — body, headings and quote blocks change together, so you never end up with a heading in one colour and a quote in another.

The three font sizes differ mainly in the relationship between section headings and the body. Medium is closest to the platform default; small suits information-dense accounts that need to fit more in; large suits accounts with fewer words per piece and a more casual reading context. Once chosen, keep it consistent across an account — changing it between pieces forces readers to re-adapt every time.

Frequently Asked Questions

The styling is gone after pasting — what now?

Most of the time you pasted as plain text instead of keeping formatting. If it still fails, a CSS property the editor does not support is usually the cause — try a different theme and regenerate, since themes have different CSS coverage.

Can tables be used directly?

Rich-text editors have limited table support, and converted tables tend to break on narrow screens. If a table is essential, turn it into an image first: produce a Markdown table in Table to Markdown, then screenshot and paste. The reasoning is in How to Write Markdown Tables.

How do I insert images?

The Markdown image syntax ![](url) only accepts publicly reachable URLs, and the editor treats it as an ordinary external image that it re-loads. The safer approach is to insert images in the editor first, then position the text around them. The tool does not host images for you.

Is my content uploaded to a server?

No. Parsing, rendering and copying all happen in the browser. The text and styling you enter never pass through any server, and no login is required. Closing the tab leaves no trace.

Summary

The whole approach rests on one move: split writing from layout, and think only about content and structure while writing. Markdown handles structure, the converter turns it into markup the editor can accept, and the editor is left for checking images and code blocks.

If the same piece also needs a set of cards, use Markdown to Image Cards to generate them. For image sourcing, use the licence notes in Free Images, Icons & Fonts Directory and the method in How to Read a Free Image License.