There Is No Center Button in Markdown — What Actually Works for Aligning Text

Markdown has one native alignment mark: colons in a table's delimiter row, and they move columns only. Everything else borrows HTML. To center a paragraph and keep its Markdown working, put a blank line after <div align="center">. Leave that line out and bold prints as literal asterisks in most setups tested.

The button in the title is a figure of speech — some editors may well have one, and toolbars were not surveyed here. The format underneath has no such mark, which is why "Markdown native text alignment" has collected 610,981 views on Stack Overflow since 2012 ¹. Its top answer says native Markdown cannot do it. Its second-ranked answer, at 150 votes, recommends <center> ² — a tag GitHub deletes ³.

For which HTML survives which app, read our color and alignment matrix; the one-line version is that <div align> survives GitHub and style does not. This page covers what that one leaves open: where the blank line goes, and why <p align> behaves differently. It also covers the table syntax that really is native, how to center a whole table, and what the most-starred READMEs use.

Every result below was measured on 31 October 2026 — 26 Markdown cases through 14 renderer setups, each laid out in Chromium 156 ³.

The quick reference: what to type for each job

Seven jobs, seven answers. Prose takes an aligned <div> with blank lines, or an aligned tag with HTML inside it. A column takes colons. A whole table takes the <div> wrapper. Each recipe below held on GitHub, marked and pandoc's gfm reader; the last column names where it did not ³.

One exception runs through every row with a tag in it.

Default markdown-it and default micromark print the tag as text, because they escape raw HTML. That is a safe default, not a defect — a host that turns HTML on behaves like commonmark.js ³.

Why Markdown has no alignment syntax

Markdown's scope leaves alignment out. John Gruber's 2004 syntax page limits the format to what plain text can convey and hands the rest to HTML. No sentence in Gruber, CommonMark or the GFM spec discusses omitting alignment, so "deliberately excluded" is an inference. The scope statement is the part with a source.

Gruber's framing is one line: "HTML is a publishing format; Markdown is a writing format."

From that he draws the limit — "Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text." ⁴ He also ruled out the obvious workaround as a design goal: "The idea is not to create a syntax that makes it easier to insert HTML tags." ⁴

Centering is a fact about a page. A plain-text file has no page.

CommonMark 0.31.2, the 2024 spec, holds to that. The word center appears once in its prose — in a list of HTML tag names. Alignment otherwise surfaces only in the question "Can ordered list markers be right-aligned?" ⁵ So the spec has zero alignment syntax, a narrower claim than zero mentions.

Nobody has closed the door either. On the CommonMark forum, "Consistent attribute syntax" ran to 143 posts between 2014 and 2022 ⁶, and "Generic directives/plugins syntax" to 173 posts between 2014 and 2025 ⁷. Neither is in the spec.

One participant's 2016 reply is the nearest thing found to a ruling on alignment — and it is only a forum post: "Since right alignment is not on the 1.0 release roadmap if specified this feature would likely be part of an extension to CommonMark." ⁸

The one native syntax: colons in a table

Colons in a table's delimiter row are the one alignment mark with a place in a Markdown spec. They trace to Michel Fortin's PHP Markdown Extra and now sit in GitHub Flavored Markdown. They align columns only — never prose — and CommonMark's core has no tables, so they need a renderer with tables enabled.

| Left | Center | Right |
|:-----|:------:|------:|
| a    | b      | c     |

Fortin's wording is still the plainest: "You can specify alignment for each column by adding colons to separator lines." And on the case people search for: "colons at both side means the column is center-aligned." ⁹

The GFM spec uses the same marks. A delimiter cell holds "hyphens (-), and optionally, a leading or trailing colon (:), or both, to indicate left, right, or center alignment respectively." ¹⁰ GitHub's own docs repeat it: "You can align text to the left, right, or center of a column by including colons" ¹¹.

A :---: gave a centered cell in 10 of 14 setups. The other four — commonmark.js, pandoc's commonmark reader and Python-Markdown in the two configurations without tables — produced no table at all ³.

The output differs even where the table works. GitHub, micromark and marked emit an align attribute; markdown-it, pandoc and Python-Markdown emit style ³. That only matters if the HTML passes through a sanitizer later — but style is the attribute GitHub removes.

Colons also set the header cell, and browsers can get a say there. GitLab's docs warn: "In GitLab, table headers are always left-aligned in Chrome and Firefox, and centered in Safari." ¹² GitLab was not rendered for this page, so that line is theirs.

For the rest of what a table can hold, see what fits in a Markdown table cell; the cheat sheet has the basic table syntax.

The blank-line rule: where Markdown starts inside aligned HTML

A blank line ends an HTML block. In CommonMark, everything from <div align="center"> to the first blank line passes through as raw HTML, unparsed. Markdown can only begin after that line. Put one right after the opening tag and bold stays bold; omit it and the asterisks print on the page.

This works on GitHub — it is the recipe to memorize:

<div align="center">

**Centered, and still bold**

</div>

These two look nearly the same and fail the same way — the word is centered, and the asterisks are visible:

<div align="center">**Not bold**</div>

<div align="center">
**Not bold**
</div>

The rule comes from the spec's definition of this kind of HTML block: "End condition: line is followed by a blank line." ⁵ The same bold word, tested five ways, shows that only the first blank line counts. That result held on GitHub, commonmark.js, marked, pandoc's gfm and commonmark readers, and markdown-it and micromark with HTML on ³.

The second blank line changes nothing measurable. Keep it anyway — the source reads better.

This behavior is younger than Markdown itself. Gruber's page is flat about it: "Note that Markdown formatting syntax is not processed within block-level HTML tags." And: "E.g., you can’t use Markdown-style *emphasis* inside an HTML block." ⁴ The CommonMark spec records the split. It notes one respect "in which Gruber’s rule is more liberal than the one given here, since it allows blank lines to occur inside an HTML block." ⁵

Three exceptions do not follow the blank-line rule:

• Python-Markdown stays with Gruber: "By default, Markdown ignores any content within a raw HTML block-level element." ¹³ The word centers and the asterisks print, with or without blank lines.
• Python-Markdown with md_in_html parses inside, given a markdown="1" attribute. PHP Markdown Extra offers the same idea: "Markdown Extra gives you a way to put Markdown-formatted text inside any block-level tag." ⁹ That attribute does nothing on GitHub ³.
• pandoc's markdown reader parses inside regardless: "For example, one can surround a block of Markdown text with <div> tags without preventing it from being interpreted as Markdown." ¹⁴ It gives bold without the blank line and no centering — the rewrite is covered in the matrix post.

A caveat on scale: this is a first-try failure, not a published epidemic. A scan of 983 READMEs flagged three with Markdown syntax stuck inside an aligned block, and one of those was a false positive in a comment — two at most ¹⁵. Authors appear to see the asterisks and fix them before pushing.

Why blank lines inside <p align> remove the centering

The fix that rescues <div> breaks <p>. Add blank lines inside <p align="center"> and the renderer emits a second paragraph inside the first. A browser will not nest them, so it closes the aligned paragraph while still empty — and your text lands on the left with its formatting intact.

<p align="center">

**Bold, but left-aligned**

</p>

This is the quieter failure — no stray asterisks, nothing that looks wrong except the position. Most renderers tested output this:

<p align="center">
<p><strong>TARGET</strong></p>
</p>

GitHub returns the already-closed form, <p align="center"> then </p> then the text in a fresh paragraph. Either way, Chromium placed the word at the left edge in all 9 setups that keep the tag and parse the inside ³. The three Python-Markdown setups stay centered, because they never parse the inside, and print asterisks instead.

The fix is HTML inside the tag, on one line:

<p align="center"><strong>Centered and bold</strong></p>

The same trace shows up on real pages. shiyu-coder/Kronos renders an empty <p align="center" dir="auto"> immediately before a heading ¹⁶. In the census, 10 of 983 READMEs produce an emptied aligned <p> — and several are harmless, because the inner element carries its own align ¹⁵.

GitHub deletes <center>, and a popular answer still recommends it

<center> centers in 11 of 14 setups tested. The three exceptions are two renderers that escape all HTML by default, and GitHub, which removes the tag and keeps the text. So the 150-vote answer on Stack Overflow's "native text alignment" thread gives advice that fails on GitHub, whichever way you space it ³.

The output has no tag at all, in both of GitHub's API modes ³.

Real pages agree — the source of ocornut/imgui contains <center><b><i>, and its rendered article contains no <center ¹⁶.

The deletion looks odd against the history. HTML 4.01 said in 1999: "The CENTER element is exactly equivalent to specifying the DIV element with the align attribute set to "center". The CENTER element is deprecated." ¹⁷ GitHub treats the two differently anyway.

A public sanitizer library, gjtorikian/html-pipeline, lists align among its allowed attributes for all elements and has no center in its element list ¹⁸. That is consistent with what GitHub does — it is not proof of GitHub's production allowlist.

Obsolete does not mean broken.

The WHATWG standard lists "align on div elements" and "align on p elements" among its non-conforming features ¹⁹, so align is wrong to write by the book — and still required to render. The same section lists center, and Chromium still honors it — it failed here because of a sanitizer, not a browser.

Inline style shares the problem. A <div style="text-align:center"> with blank lines centers in the same 11 setups and loses its centering on GitHub ³ — fastapi/fastapi has it in its source and none in its rendered README ¹⁶.

Center an image or a heading

Images and headings follow the same two rules. Use HTML inside an aligned tag, or use Markdown after a blank line inside a <div>. The combination that fails is Markdown inside a one-line <p align> — GitHub prints the image syntax as text rather than showing a picture ³.

For an image, this is the most portable form tested — it centered in 12 of 14 setups, including all three Python-Markdown configurations, and it answers a question with 604,139 views ¹:

<p align="center"><img src="logo.png" alt="Project logo" width="200"></p>

This is the trap version, which prints as text on GitHub:

<p align="center">![Project logo](logo.png)</p>

Markdown image syntax does work inside a <div>, after a blank line. Python-Markdown prints it as text, and pandoc's markdown reader shows the image uncentered ³. For how image sizing travels between apps, see the image-size post.

A heading has two forms. The first needs HTML inside, since Markdown does not parse there:

<h2 align="center">Project name</h2>

The second keeps the ## in your source:

<div align="center">

## Project name

</div>

Python-Markdown prints that ## literally, and pandoc's markdown reader gives the heading without centering it ³.

Center a whole table

Wrap the table in <div align="center">, with a blank line after the opening tag. In Chromium, the table's midpoint landed at 400 on an 800-pixel page. Inside style="text-align:center" the same table sat at 56. Only the align form moves the table, because text-align alone centers inline content, not a table box.

<div align="center">

| Name | Value |
|------|-------|
| a    | 1     |

</div>

The WHATWG rendering section explains the difference — elements with align=center behave "as if they had their 'text-align' property set to 'center' in a presentational hint, and to align descendants to the center." ²⁰ That second clause is what moves the table. Under the published github-markdown-css 5.9.0 stylesheet the midpoints were 400 for align and 78 for style ²¹.

GitHub keeps the wrapper.

This exact example went through GitHub's API in both modes, and the <div align="center"> came back around the table ³. Five real READMEs with the same pattern, deepseek-ai/DeepSeek-V3 among them, render the same way on their repository pages ²².

This is the question with 150,177 views ¹, and the limits matter. The midpoints above come from Chromium with published CSS, not from Firefox or Safari. On live repository pages, also in Chromium, the two narrower tables checked — 568 pixels wide in microsoft/markitdown, 513 in deepseek-ai/DeepSeek-V3 — sat on the article's midpoint ²². Other renderers split too: commonmark.js, pandoc's commonmark reader and Python-Markdown leave the pipes as text, and pandoc's markdown reader shows the table uncentered ³.

Right-align and justify

<div align="right"> with a blank line after it right-aligns prose on every renderer that centers with the <div> recipe. align="justify" works the same way, and Chromium computes justify. It is honored, but none of the 983 READMEs in the census uses it on a block tag, and the research offers little reason to start.

<div align="right">

Signed, 31 October

</div>

"How to right-align and justify-align in Markdown?" has 312,963 views ¹. The nearest evidence on justify comes from Jonathan Ling and Paul van Schaik, writing in Displays in 2007: "Left-aligned text led to better performance, although participants preferred justified text." ²³

That was a visual-search task on web pages.

It did not test centered text — and the same paper also reported on spacing, which the line-height post covers.

Dialect syntaxes that print as junk elsewhere

Several Markdown dialects offer real alignment syntax, and each prints as visible junk outside its home. pandoc has fenced divs. Python-Markdown's attr_list and markdown-it-attrs take attribute lists. The arrow form -> text <- centered in none of the 14 setups. Use these only when you control the renderer.

pandoc's documented form: "A Div starts with a fence containing at least three consecutive colons plus some attributes." ²⁴

::: {style="text-align:center"}
Centered in pandoc
:::

Python-Markdown's: "To define attributes for a block level element, the attribute list should be defined on the last line of the block by itself." ²⁵

Centered here
{: style="text-align:center"}

And for md_in_html, the attribute goes on the tag — no blank lines needed:

<div align="center" markdown="1">
**Centered and bold**
</div>

Attribute lists have a lineage of their own. kramdown's docs say of its version: "This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from the Maruku package." ²⁶ John MacFarlane's Djot, a separate format, moves them to the front: "To attach attributes to a block-level element, put the attributes on the line immediately before the block." ²⁷ Neither kramdown nor Djot was rendered for this page.

What the most-starred READMEs actually use

Of the 1,000 most-starred GitHub repositories, 983 had a readable Markdown README, and 547 of those — 55.6% — use a block-level align set to center or middle. Only 78 center a table column, 12 use text-align in a style, and 4 use <center>. In this sample, the obsolete attribute is the default.

The list has limits, so read it narrowly ¹⁵. This is most-starred repos, not Markdown users — and that list skews to developers. A README counts once if any matching tag exists. The block counts look at div, p and h1 through h6, with code and comments stripped first. Six random hits were spot-checked by hand — all real. The repositories ranged from 34,547 to 557,793 stars when fetched on 31 October 2026.

The HTML standard calls that attribute obsolete. On GitHub, it is also the form that survives.

Should you center text at all?

Left-align long text by default — but not because science has settled it. The one direct experiment found, a US Census Bureau test with 30 older adults on smartphones, reported no significant difference in reading speed or comprehension between left-aligned and centered text. Most preferred left. Two search passes turned up no peer-reviewed comparison of centered and left-aligned prose.

The report, by Figueroa, Rivas and Wang, came out in 2022 and is a government research report, not a peer-reviewed paper. As printed: "Thirty participants took part in this study between July and August 2016." Their ages ran from 61 to 85, and they read two reading-test passages of about 160 words each on an iPhone 6s ²⁸.

Speed: "not statistically significant (t(17) = 0.65, p = .52)." Comprehension: "not statistically significant (p = .35)." Preference: "Eighty percent of participants preferred the left-alignment design while 20% center-alignment." Its advice stays inside its scope — "We recommend that text be displayed in left alignment for a survey on a smartphone." ²⁸

Those numbers carry a loose end — the report says "reading time data for 11 participants were not recorded, resulting in a sample size of n = 18." Thirty, eleven and eighteen do not reconcile, and the report does not explain the gap ²⁸. All numbers here are as printed.

So a small null result is all there is — and a null result this small does not prove the two are equal. The defensible line is modest: readers in that test preferred left, and it found no measured cost to centering. This search found no proof that centered text is harder to read, and none that it isn't.

A centered logo or title on a README asks little of a reader.

Three centered paragraphs are a judgment call, and left is the safer one.

How this was tested, and what was not

All results come from 26 cases through 14 renderer setups on 31 October 2026, with positions measured in Chromium 156. GitHub was tested through its Markdown API and on real repository pages. Firefox, Safari, Obsidian, VS Code, GitLab and Typora were not run, so this page makes no claim about them.

The 14 setups ³:

• GitHub — POST /markdown, markdown mode, with gfm mode on the key cases
• commonmark.js 0.31.2
• markdown-it 15.0.3 — default, html: true, and html: true with markdown-it-attrs 5.0.1
• micromark 4.0.3 with its GFM extension — default and allowDangerousHtml
• marked 18.1.2
• pandoc 3.13 — markdown, gfm and commonmark readers
• Python-Markdown 3.11.2 — default, tables with attr_list, and md_in_html

These are default settings, labeled as such. A host can change them — and GitHub can change its sanitizer without notice. Nothing here describes how any note app renders alignment — check your own preview.

FAQ

These seven questions use the wording people typed into Stack Overflow. Answers describe the renderers tested on 31 October 2026. Nothing here covers an app that was not run, including Obsidian, VS Code and Typora, so check your own preview before relying on a recipe in one of those.

Markdown native text alignment

For prose, there is none: no mark in Gruber's Markdown, CommonMark or GitHub Flavored Markdown aligns a paragraph. The native syntax covers table columns only, through colons in the delimiter row, and it needs a renderer with tables enabled. Anything else is raw HTML, or a dialect extension that prints as text elsewhere.

How to center text with Markdown?

Open with <div align="center">, leave a blank line, write your Markdown, leave another blank line, and close the div. Without the first blank line, bold prints as literal asterisks on GitHub and most other setups tested. Python-Markdown stays literal either way, and pandoc's markdown reader does not center it.

How do I center an image in the README.md file on GitHub?

Use <p align="center"><img src="logo.png" alt="Project logo" width="200"></p>. That form centered in 12 of 14 setups tested, including GitHub. Do not put Markdown image syntax inside that one-line paragraph tag, because GitHub prints it as text. A Markdown image works only inside a <div>, after a blank line.

How to right-align and justify-align in Markdown?

Use <div align="right"> or <div align="justify">, then a blank line, your text, another blank line, and </div>. GitHub kept both, and Chromium computed the matching alignment. Prose has no Markdown syntax for either. None of the 983 READMEs in the census used a block-level align="justify".

Is it possible to center tables in a markdown file?

Yes, with raw HTML. Wrap the table in <div align="center">, with a blank line after the opening tag and before the closing one. In Chromium that put the table's midpoint at the page's midpoint, while style="text-align:center" did not. Colons in the delimiter row align text inside columns, not the table itself.

How do you center text in Gitlab markdown?

This page has no tested answer, because no GitLab render was run. GitLab's docs do note one table quirk: headers "are always left-aligned in Chrome and Firefox, and centered in Safari." Try the blank-line <div> recipe in a GitLab preview before relying on it, and treat the GitHub results here as GitHub's only.

Left-align headers in Markdown table?

Put the colon on the left of that column's delimiter cell, as in :---. In GFM the delimiter row sets alignment for the whole column, header included, and there is no separate header setting. GitLab documents a browser difference for headers, so check your own host if header alignment matters to you.

Markdown never promised you a center. It promised a file that still reads when the centering fails.

mnmnote.com keeps notes as open Markdown on your own device — offline, with no account.