GitHub Markdown and README Formatting
Every GitHub Flavored Markdown feature with copy-ready examples: alerts, tables, task lists, math, Mermaid, image sizing, the HTML GitHub allows, and a README template to start from.
Short answer
GitHub renders GitHub Flavored Markdown: standard Markdown plus tables, task lists (- [ ]), strikethrough (~~text~~) and autolinked URLs, with GitHub's own alerts (> [!NOTE]), math ($x^2$), Mermaid diagrams and emoji (:tada:) on top. The catch is that a README and an issue comment do not render the same: in a .md file a single newline is a space and #123 stays plain text. And GitHub strips style and class from HTML, so images are sized with width and centered with align="center".
README Files vs Issue Comments
GitHub renders Markdown in two places with slightly different rules: repository files (README.md and every other .md file) and conversations (issues, pull requests, discussions, and their comments). Most “it worked in my issue but not my README” problems come from this table.
| You write | In a .md file | In an issue, PR, or discussion |
|---|---|---|
| A single newline | Joined into one line | Line break |
| #123, GH-123, owner/repo#123 | Plain text | Link to the issue or pull request |
| A commit SHA | Plain text | Short link to the commit |
| `#0969DA`, `rgb(…)`, `hsl(…)` in backticks | Plain inline code | Inline code with a color swatch |
| - [ ] task list | Read-only checkboxes | Clickable if you can edit the comment |
| Full URLs, emoji, alerts, tables, math, Mermaid | Rendered | Rendered |
This example
Will span two linesThis example Will span two lines
This example
Will span two linesThis example
Will span two lines
To force a break in a file, end the line with a backslash, two spaces, or <br> (see line breaks). Our Markdown editor can preview either mode. Wikis have their own gaps: footnotes and autolinked references are not supported there.
Text Styling
Bold, italic, and strikethrough use standard syntax; GitHub accepts one or two tildes for strikethrough. There is no Markdown for underline, subscript, or superscript, so GitHub documents the HTML tags <ins>, <sub>, and <sup>. The older <u> tag is stripped (see underline).
**Bold** or __bold__
*Italic* or _italic_
***Bold and italic***
~~Strikethrough~~ or ~one tilde~
H<sub>2</sub>O and x<sup>2</sup>
<ins>Underlined</ins>
`inline code`Bold or bold
Italic or italic
Bold and italicStrikethrough or one tilde
H2O and x2
Underlinedinline code
Keyboard shortcuts in GitHub's editor
These work in comment boxes and the file editor on github.com.
| Action | Windows / Linux | macOS |
|---|---|---|
| Bold | Ctrl+B | Cmd+B |
| Italic | Ctrl+I | Cmd+I |
| Inline code | Ctrl+E | Cmd+E |
| Link | Ctrl+K | Cmd+K |
| Link from selected text | Select text, Ctrl+V a URL | Select text, Cmd+V a URL |
| Bulleted / numbered list | Ctrl+Shift+8 / Ctrl+Shift+7 | Cmd+Shift+8 / Cmd+Shift+7 |
| Quote | Ctrl+Shift+. | Cmd+Shift+. |
| Toggle Write / Preview (comments) | Ctrl+Shift+P | Cmd+Shift+P |
| Quote selected text in a reply | R | R |
Alerts (Callouts)
Alerts are blockquotes whose first line is [!TYPE]. GitHub has five types and draws each with its own color and icon. The type must sit alone on the first line, is case-insensitive, and the alert cannot be nested inside a list or another quote. GitHub's own advice is one or two per document, never back to back.
> [!NOTE]
> Useful information that users should know, even when skimming content.Useful information that users should know, even when skimming content.
> [!TIP]
> Helpful advice for doing things better or more easily.Helpful advice for doing things better or more easily.
> [!IMPORTANT]
> Key information users need to know to achieve their goal.Key information users need to know to achieve their goal.
> [!WARNING]
> Urgent info that needs immediate user attention to avoid problems.Urgent info that needs immediate user attention to avoid problems.
> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.Advises about risks or negative outcomes of certain actions.
Obsidian reads the same > [!NOTE] syntax as a callout and adds many more types (see Obsidian Markdown); GitHub only recognizes these five.
Tables
Pipes separate columns and a row of hyphens separates the header. Colons in that row set alignment: :--- left, :---: center, ---: right. Cells can hold inline formatting, links, and code; a literal pipe inside a cell needs a backslash (\|). The outer pipes are optional and the columns do not have to line up.
| Command | Description | Exit code |
| :--- | :---: | ---: |
| `git status` | List *changed* files | 0 |
| `git diff` | Show **unstaged** changes | 0 |
| a \| b | Escaped pipe | 1 || Command | Description | Exit code |
|---|---|---|
git status |
List changed files | 0 |
git diff |
Show unstaged changes | 0 |
| a | b | Escaped pipe | 1 |
More on merged-cell workarounds and line breaks in cells in the table guide, or build one with the table generator.
Task Lists
Start a list item with [ ] for an open task or [x] for a done one. Bulleted and numbered lists both work. In issues, pull requests, and comments the checkboxes are clickable and GitHub rewrites the Markdown for you; in a .md file they are read-only. In conversations, a task item that references an issue or PR shows that issue's title and state.
- [x] Write the parser
- [x] Add tests
- [ ] Update the README
- [ ] Tag a release- Write the parser
- Add tests
- Update the README
- Tag a release
GitHub retired the separate tasklist blocks beta in 2025 in favor of sub-issues. Ordinary Markdown task lists like the one above are unaffected. Nesting and per-platform behavior are covered in the checkbox guide.
Code Blocks and Diagrams
Fence code with three backticks and add a language identifier for syntax highlighting. GitHub uses Linguist to pick the grammar, so any name or alias in its languages list works (js, python, diff, bash). To show triple backticks inside a block, fence it with four.
```js
const answer = 42
console.log(answer)
``````mermaid
graph TD;
A-->B;
A-->C;
B-->D;
C-->D;
```Four language identifiers turn a code block into a rendered diagram, in files, issues, pull requests, discussions, and wikis:
| Fence with | Renders |
|---|---|
| ```mermaid | Flowcharts, sequence diagrams, Gantt charts, pie charts and the rest of Mermaid |
| ```geojson | An interactive map from GeoJSON |
| ```topojson | An interactive map from TopoJSON |
| ```stl | An interactive 3D model from ASCII STL |
Not sure GitHub supports a newer Mermaid feature? A mermaid block containing only info prints the version GitHub is running. Full fencing rules are in the code block guide.
Math (LaTeX)
GitHub renders LaTeX math with MathJax in files, issues, pull requests, discussions, and wikis. There are two inline forms and two block forms:
Pythagoras: $a^2 + b^2 = c^2$Use $`\sqrt{3x-1}+(1+x)^2`$ when the expression has * or _$$
\sum_{k=1}^n k = \frac{n(n+1)}{2}
$$```math
\sum_{k=1}^n k = \frac{n(n+1)}{2}
```A literal dollar sign on the same line as math needs escaping: \$ inside an expression, or <span>$</span> outside one.
$\color{orange}{\text{This is orange text}}$Because GitHub strips CSS, people color text with MathJax's \color command. It is not a GitHub-documented feature, it renders in a math font, and links inside it do not work. Other options are in the text color guide.
Autolinks, Mentions, Emoji, and Color Swatches
GitHub turns some plain text into links or widgets. Watch the last column: issue, PR, and commit references are not linked in README or other repository files, or in wikis.
| Type | You write | GitHub shows | Where |
|---|---|---|---|
| Full URL | https://github.com | A clickable link | Everywhere |
| Issue or PR number | #26 | Link to issue or PR #26 in this repo | Conversations only |
| GH- prefix | GH-26 | Same as #26 | Conversations only |
| Another repo | owner/repo#26 | Link to #26 in that repository | Conversations only |
| Issue or PR URL | https://github.com/owner/repo/issues/26 | Shortened to #26 (or owner/repo#26) | Conversations only |
| Commit SHA | a5c3785ed8d6a35868bc169f07e40e889087fd2e | Shortened to a5c3785, linked | Conversations only |
| Commit in another repo | owner/repo@a5c3785… | owner/repo@a5c3785, linked | Conversations only |
| Mention | @octocat or @org/team | Link to the profile, and a notification | Conversations |
| Emoji shortcode | :tada: :+1: :shipit: | 🎉 👍 and GitHub's own squirrel | Everywhere |
| Color model | `#0969DA` | Inline code with a color swatch | Issues, PRs, discussions |
“Conversations” means issues, pull requests, discussions, and their comments. A mention notifies someone only if they have read access to the repository (and, for an organization's repository, are a member of the organization). Color models (#RRGGBB, rgb(R,G,B), hsl(H,S,L)) need backticks and no spaces inside them. For emoji, type : in a comment box to search, or see the full shortcode list.
Section Links and Relative Links
Every heading gets an anchor. GitHub builds it by lowercasing the text, turning spaces into hyphens, dropping other punctuation and Markdown formatting, and adding -1, -2 to repeats. Rendered files with two or more headings also get an automatic table of contents under the Outline button.
## Getting Started
## FAQ & Troubleshooting
[Jump to setup](#getting-started)
[Read the FAQ](#faq--troubleshooting)
[Contributing guide](docs/CONTRIBUTING.md)
[Repo-root path](/LICENSE)
<a name="config"></a>
[Jump to config](#config)- #getting-started
- Lowercased, space becomes a hyphen
- #faq--troubleshooting
- & is dropped, both spaces stay as hyphens
- docs/CONTRIBUTING.md
- Relative to the current file, on the current branch
- /LICENSE
- A leading slash starts at the repository root
- #config
- Custom anchor from <a name>; not listed in the Outline
Prefer relative links for files in your own repo: GitHub rewrites them for whatever branch the reader is on, and they keep working in clones. Keep the link text on one line. More on IDs in the headings guide and on link syntax in the links guide.
Images: Size, Center, and Dark Mode
 works everywhere, but Markdown has no size or alignment option. On GitHub you switch to an <img> tag, which keeps width, height, and align. For images in your repo, use a relative path such as docs/screenshot.png.
<img src="docs/screenshot.png" width="400" alt="Dashboard screenshot"><p align="center">
<img src="docs/logo.png" width="150" alt="App logo">
</p>
<h3 align="center">Centered Title</h3><picture>
<source media="(prefers-color-scheme: dark)" srcset="docs/logo-dark.png">
<source media="(prefers-color-scheme: light)" srcset="docs/logo-light.png">
<img alt="Project logo" src="docs/logo-light.png">
</picture>To make an image clickable, wrap the image in a link. More patterns in the images guide and the centering guide.
What HTML GitHub Allows
GitHub runs your HTML through a sanitizer before rendering it. A small set of tags and attributes survives; anything that could restyle the page is removed. Checked against GitHub's Markdown rendering API.
Survives
- <details>, <summary>
- Collapsible sections, including the open attribute
- <sub>, <sup>
- Subscript and superscript
- <ins>
- Underline (GitHub's documented way)
- <kbd>, <mark>
- Keyboard keys and highlighted text
- <img width height align alt>
- Sizing and floating images
- <picture>, <source>
- Different images for light and dark mode
- align="center" on <p>, <div>, <h1>–<h6>
- The one way to center content
- <br>, <a name="…">
- Line breaks and custom link anchors
Stripped or changed
- style="…"
- Removed from every element, so no inline CSS, colors, or fonts
- class="…"
- Removed, so no styling hooks
- id="…"
- Kept, but rewritten with a user-content- prefix
- <script>, <iframe>, <style>, <textarea>
- Escaped, so the tag prints as literal text (GFM's tagfilter)
- <form>, <input>
- Removed
- <u>
- Tag removed, text kept. Use <ins> instead
- <center>, <font>
- Tags removed, text kept. Use align or the math color trick
HTML comments (<!-- -->) are hidden from the rendered page but stay readable in the raw file. See Markdown comments.
Collapsible Sections
<details> and <summary> fold long logs, options, or screenshots behind a click. Leave a blank line after </summary>, or the Markdown inside prints as raw text. Add open to start it expanded.
<details>
<summary>System details</summary>
### Environment
- macOS 15
- Node 22.11.0
</details>System details
Environment
- macOS 15
- Node 22.11.0
Nesting, headings in the summary, and the indentation trap are in the collapsible sections guide.
Footnotes
Put [^label] where the reference goes and define it anywhere on its own line. GitHub numbers them in order and always renders the notes at the bottom, with a link back. Footnotes work in files and conversations but not in wikis.
GFM is defined by a formal spec.[^1]
[^1]: Published at github.github.com/gfm.GFM is defined by a formal spec.1
Multi-paragraph notes and other platforms: footnotes guide.
README Template
GitHub's own guidance is that a README should say what the project does, why it is useful, how to get started, where to get help, and who maintains it. This template covers that with the features above. Replace OWNER/REPO and the file paths.
<div align="center">
<img src="docs/logo.png" width="120" alt="Project logo">
# Project Name
One sentence on what this does and who it is for.
[](https://github.com/OWNER/REPO/actions/workflows/ci.yml)
[](LICENSE)
</div>
## Why
The problem this solves, in two or three sentences.
## Installation
```bash
npm install project-name
```
## Usage
```js
import { thing } from "project-name"
thing({ verbose: true })
```
> [!NOTE]
> Requires Node.js 20 or later.
## Contributing
Pull requests are welcome. See [CONTRIBUTING.md](CONTRIBUTING.md).
## License
[MIT](LICENSE)- GitHub shows the README from
.github/, the repository root, ordocs/, in that order of preference when there is more than one. - Anything past 500 KiB is cut off when the README is viewed on GitHub.
- A public repository named exactly like your username turns its README into your profile README, shown at the top of your profile page.
- The blank lines inside the centered
<div>are what let the heading and badges render as Markdown.
Common Mistakes
The formatting problems that come up most in READMEs and issue threads.
Doesn't work
See #42 for the background.Fixed
See [#42](https://github.com/OWNER/REPO/issues/42) for the background.Doesn't work
Line one
Line twoFixed
Line one\
Line twoDoesn't work
<span style="color:red">Deprecated</span>Fixed
> [!WARNING]
> Deprecated: use v2 instead.Doesn't work
> [!NOTE] Read this first.Fixed
> [!NOTE]
> Read this first.Doesn't work
<u>underlined</u>Fixed
<ins>underlined</ins>Doesn't work
<details>
<summary>Logs</summary>
**Bold** and `code`
</details>Fixed
<details>
<summary>Logs</summary>
**Bold** and `code`
</details>Doesn't work
{width=200}Fixed
<img src="logo.png" width="200" alt="Logo">Quick Reference
Every GitHub Markdown feature on this page at a glance.
| Feature | Syntax | Works in |
|---|---|---|
| Bold / italic | **bold** *italic* | Everywhere |
| Strikethrough | ~~text~~ or ~text~ | Everywhere |
| Underline | <ins>text</ins> | Everywhere |
| Sub / superscript | <sub>2</sub> <sup>2</sup> | Everywhere |
| Alert | > [!NOTE] > [!TIP] > [!IMPORTANT] > [!WARNING] > [!CAUTION] | Everywhere |
| Table | | a | b | | --- | --- | | Everywhere |
| Task list | - [ ] todo - [x] done | Clickable in comments |
| Code block | ```js … ``` | Everywhere |
| Diagram | ```mermaid ```geojson ```topojson ```stl | Everywhere |
| Inline math | $x^2$ or $`x^2`$ | Everywhere |
| Block math | $$ … $$ or ```math | Everywhere |
| Footnote | text[^1] then [^1]: note | Not in wikis |
| Collapsible | <details><summary>…</summary> | Everywhere |
| Image size | <img src="…" width="300"> | Everywhere |
| Center | <p align="center">…</p> | Everywhere |
| Section link | [Install](#installation) | Everywhere |
| Emoji | :tada: | Everywhere |
| Issue reference | #123 owner/repo#123 | Conversations only |
| Mention | @username | Conversations |
| Color swatch | `#0969DA` | Issues, PRs, discussions |
| Hidden comment | <!-- not rendered --> | Everywhere |
Frequently Asked Questions
What is GitHub Flavored Markdown (GFM)?
GitHub Flavored Markdown is GitHub's dialect of Markdown, published as a formal spec on top of CommonMark. The spec adds tables, task list items, strikethrough, extended autolinks, and a filter for unsafe raw HTML. GitHub.com then layers its own features over that: alerts, math, Mermaid and map diagrams, footnotes, emoji shortcodes, @mentions, and issue references.
How do I format a README on GitHub?
Create a file named README.md in the repository root (GitHub also checks .github/ and docs/) and write it in Markdown: # for headings, - for lists, triple backticks for code, pipes for tables. Use the Preview tab in the web editor to check it before committing. Anything Markdown cannot do, such as sizing or centering an image, is done with a small set of allowed HTML tags.
What format should a README file be?
Markdown, saved as README.md, is the standard and what GitHub renders with the most features. GitHub's markup library can also render README.rst, README.adoc, README.org, and a few other formats, but alerts, task lists, and Mermaid are Markdown features.
How do I make my GitHub README look good?
Lead with a centered header (logo, project name, one-line description, a few badges) using <div align="center">, then short sections: why, installation, usage, contributing, license. Show a screenshot, use <picture> if it needs light and dark versions, put long logs or options in <details>, and keep alerts to one or two. GitHub builds a table of contents from your headings automatically, so a manual one is optional.
Why isn't #123 turning into a link in my README?
Because autolinked references for issues, pull requests, and commits are only created in conversations: issues, pull requests, discussions, and comments. GitHub's docs state they are not created in wikis or files in a repository. In a README, write a normal Markdown link to the issue URL.
How do I add a line break in a GitHub README?
End the line with a backslash, two trailing spaces, or <br>. In a .md file a single newline is treated as a space, so two lines written one under the other render as one line. In issues, pull requests, and discussions GitHub renders a single newline as a line break, which is why the same text can look different in a comment.
How do I color text in GitHub Markdown?
GitHub strips the style attribute, so <span style="color:red"> renders in the normal color. The common workaround is LaTeX color inside math: $\color{red}{\text{your text}}$. It is not a documented GitHub feature and it renders in a math font. For warnings and emphasis, an alert such as > [!WARNING] is the supported option.
How do I resize an image in GitHub Markdown?
Markdown image syntax has no size option, so use an HTML img tag: <img src="screenshot.png" width="400" alt="Screenshot">. GitHub keeps the width, height, and align attributes. Style-based sizing (style="width: 50%") is stripped.
How do I center an image or text in a GitHub README?
Wrap it in <p align="center"> or <div align="center">. The align attribute survives GitHub's sanitizer; CSS and the old <center> tag do not. Inside a <div>, leave blank lines around any Markdown so it still renders.
Does GitHub support Mermaid diagrams?
Yes. Put Mermaid syntax in a fenced code block with the mermaid language identifier and GitHub renders it as a diagram in Markdown files, issues, pull requests, discussions, and wikis. The same works for geojson and topojson maps and stl 3D models. A block containing just info shows which Mermaid version GitHub runs.
How do I write math equations in GitHub Markdown?
Use $...$ for inline math, or $`...`$ when the expression contains characters Markdown would otherwise interpret. For a block, put $$...$$ on its own lines or use a fenced code block with the math language identifier. GitHub renders it with MathJax in files, issues, pull requests, discussions, and wikis.
How do I create a collapsible section on GitHub?
Use <details> with a <summary> label, and leave a blank line after </summary> so the Markdown inside renders. Add the open attribute (<details open>) to have it start expanded.
Why isn't my checklist rendering correctly on GitHub?
A task list item is a list marker, a space, brackets, a space, then text: - [ ] for unchecked and - [x] for checked. A missing space inside the brackets ([]) or after them breaks it. Numbered lists work too (1. [ ] task). The checkboxes are clickable in issues, pull requests, and comments; in a .md file they display but cannot be toggled.