Markdown Arrow: Symbols, Entity Names and Codes (2026)

TL;DR: Markdown defines no arrow syntax. An arrow reaches a rendered document three ways: as a raw Unicode character (→), as an HTML entity name (→), or as a numeric character reference (→). The last two are resolved by the Markdown parser at parse time, not by the browser, which is why they survive renderers that strip HTML. The trailing semicolon is mandatory, case matters, and five of the arrows below — the four solid black ones and one curving arrow — have no entity name at all.

A markdown arrow is not a markdown feature. The CommonMark specification defines no arrow construct, no shorthand, no --> that turns into →. Every arrow you have ever seen in a rendered .md file arrived by one of three routes that predate markdown entirely, and knowing which route you are on decides whether the character survives a code span, a chat app, or a sanitising renderer. This page is the reference table plus the rules that go with it. If you want the broader syntax picture first, the markdown cheat sheet covers the constructs markdown does define, and MacMD Viewer renders all three arrow routes identically in the app window and in QuickLook.

How Do You Write a Markdown Arrow?

Pick one of three routes. None of them is markdown syntax; markdown either passes the character through untouched or decodes a reference into it.

All three produce a real arrow character in the output. In a rendered document you cannot tell which one the author typed.

Two rules trip people up before they get anywhere near the table below.

The trailing semicolon is mandatory. CommonMark defines an entity reference as & plus a valid HTML5 entity name plus ;. Drop the semicolon and the text renders literally. HTML itself tolerates 106 legacy semicolon-less forms such as &amp — no arrow name is among them, so the tolerance never helps you here.

Case is significant. ← is ← LEFTWARDS ARROW. ⇐ is ⇐ LEFTWARDS DOUBLE ARROW. One capital letter, a different character. The same holds for ↔ versus ⇔ and every other single-versus-double pair.

Markdown Arrow Reference Table

Every entity name below requires the trailing semicolon. Codepoints and official Unicode names come from the Unicode Character Database; entity names come from the WHATWG named character reference list, which CommonMark declares authoritative. Copy the character straight from the first column if you would rather not type a code at all.

Cardinal arrows

Double arrows

Diagonal, hooked, circular and paired arrows

Arrows with no entity name

These five are the arrows you see in issue trackers and README badges, and they have no name in the WHATWG list. Use the character or the numeric reference. If a page offers you a name for any of them, that name does not exist.

Copy-paste block

The four cardinal directions in all three forms, ready to lift into a file:

Raw:      →  ←  ↑  ↓
Entity:   →  ←  ↑  ↓
Decimal:  →  ←  ↑  ↓
Hex:      →  ←  ↑  ↓

Every line renders the same four arrows.

Entity Names Are Decoded by the Parser, Not the Browser

This is the single most misunderstood point about arrows in markdown, and it is the reason → keeps working in places you would expect it to fail.

The common explanation is that → works "because markdown allows inline HTML." It does not. Character references are a first-class CommonMark feature with their own section in the spec, and the parser resolves them into the actual character before any HTML is emitted. By the time a renderer's HTML sanitiser sees the document, there is no entity left to sanitise — only a → sitting in a text node.

I confirmed this on the parser that ships inside MacMD Viewer. Feeding it Right → entity. Numeric → ref. Hex → ref. Raw → unicode. produces a syntax tree holding one text node, and that node already reads Right → entity. Numeric → ref. Hex → ref. Raw → unicode. The entities are gone before the HTML generator runs.

The spec's own wording sets the boundaries:

• Entity references are & + a valid HTML5 entity name + ;, with entities.json named as the authoritative source.
• Decimal references are &# + one to seven digits + ;.
• Hexadecimal references are &# + X or x + one to six hex digits + ;.
• References are recognised "in any context besides code spans or code blocks, including URLs, link titles, and fenced code block info strings."
• They "cannot stand in place of special characters that define structural elements in CommonMark" — you cannot write a numeric reference for # and get a heading.

That code-span exception is not a footnote. It is why every entity name in this article sits inside backticks, and why an entity you paste into a fenced block stays visible as text.

Scale, for context: the WHATWG list defines 2,231 named character references, folding down to 2,125 distinct names once the semicolon-less legacy duplicates are merged. Only 106 are legal without the trailing semicolon, and none of those is an arrow. On the Unicode side, 112 characters are assigned in the Arrows block (U+2190–U+21FF) out of 128 code points, with a further 253 in Miscellaneous Symbols and Arrows (U+2B00–U+2BFF). The named subset is essentially the Arrows block plus mathematical arrows, which is exactly why the emoji-style arrows in the previous table have no names.

Which Platforms Render Markdown Arrows?

Raw Unicode works everywhere the font has the glyph. Entity and numeric references work wherever a CommonMark-conformant parser runs, and stop being special the moment you leave one.

I checked GitHub against its own render API rather than trusting a claim about it. Posting Entity → numeric → hex → raw → and a code span to the /markdown endpoint in GFM mode comes back as a paragraph in which all three reference forms have become the same arrow, while the entity inside the code span has been re-escaped and is displayed literally. Two rules confirmed in one response, from GitHub's production pipeline.

VS Code's preview follows because it targets CommonMark using markdown-it. Pandoc decodes all three forms as well.

Two caveats worth stating plainly rather than guessing at. Obsidian documents its own flavour of markdown and its own parser; its help pages evidence   in notes but do not establish a general rule for the full named-entity set, so I have not asserted one. And Slack's documented message formatting set is bold, italics, underline, strikethrough, code, block quote, code block, ordered list and bulleted list — HTML entities are not in it. For Slack, Discord and chat tools generally, paste the character itself and stop worrying about codes. If you are formatting in chat regularly, the wider rules are in the markdown cheat sheet.

Does Anything Convert -> Into an Arrow Automatically?

Not in markdown, and not in the places the internet says it does.

Pandoc's smart extension does not touch arrows. I ran it both ways. With markdown+smart, "quotes" become curly, -- becomes an en dash and ... becomes an ellipsis — and -> comes out the other side escaped to ->, still two characters. With markdown-smart, nothing is transformed at all. Smart punctuation is quotes, dashes and ellipses. It has never included arrows.

Typora's Markdown Reference documents inline HTML support and says nothing about arrows, ->, smart punctuation or automatic character substitution. Notion's keyboard-shortcuts page documents markdown-style shortcuts for bold, italics, headings and --- for a divider, and no arrow substitution. Two vendor documentation pages checked, zero mentions. If your editor does convert ->, it is doing something its own docs do not describe.

The one documented, reliable route on macOS is a system feature, not an editor feature. Open Apple menu > System Settings > Keyboard > Text Replacements, or from inside an app, Edit > Substitutions > Show Substitutions and then Text Settings. Add a pair: replace -> with →, click Add, then Done. Apple documents that text replacements can be kept up to date across your Apple devices.

That last point is why it beats every per-editor trick: it fires in every app that uses the standard macOS text system. Your editor, your notes app, your terminal-adjacent GUI tools, your browser text fields. One setting, not one setting per tool.

One warning before you add that rule. If you write Mermaid diagrams, a global -> replacement will corrupt them, because --> is an edge declaration there rather than punctuation. See the Mermaid section below, and pick a trigger that never appears in diagram syntax — ;ar for → and ;al for ← work well.

How Do You Type an Arrow on a Mac?

Three approaches, in the order I reach for them.

Character Viewer. Press the Fn or Globe key together with E, or use the menu path Edit > Emoji & Symbols. Search for "arrow", then click a character to insert it at the cursor. Apple's emoji and symbols guide covers the current behaviour. Control-Command-Space is the long-standing binding for the same panel, though Apple's current documentation leads with Fn/Globe–E.

Text Replacement. The recipe above. Best if you type the same two or three arrows every day.

Copy from the reference table. For a one-off arrow in a document, copying the character out of the first column of the tables above beats either of the other two. It travels intact through git, through a diff, and through a code review comment, because it is plain text.

A note on which form to store in the file. Raw Unicode is the most portable: it renders in a terminal cat, in git log, in a diff, and in any chat app, none of which run a markdown parser. Entity names are the more readable choice when the file is edited by people who would otherwise not recognise the glyph, and they are the safer choice when a downstream toolchain mangles non-ASCII characters. Numeric references are the fallback for the arrows that have no name. If you want the arrow to be invisible in the rendered output entirely, that is a different tool — see markdown comments for source-only text.

When Is an Arrow Syntax Instead of Text? Mermaid Diagrams

In prose, an arrow is content. Inside a Mermaid fence, an arrow is syntax: --> declares an edge between two nodes, and rewriting it as → breaks the diagram. Same document, same characters, completely different meaning.

flowchart LR
  A[Write .md] --> B{Arrow route?}
  B -->|Raw Unicode| C[Passed through as text]
  B -->|Entity or numeric ref| D[Decoded at parse time]
  C --> E[Same character rendered]
  D --> E

The link forms Mermaid's flowchart syntax defines:

Link text goes either inside pipes, A -->|text| B, or between dashes, A -- text --> B. Adding dashes lengthens the link rather than changing it: ---- spans two ranks, ----- spans three, and the same applies to ==== and -..-. The Mermaid flowchart syntax guide covers node shapes, subgraphs and direction alongside these.

Two consequences for arrows specifically. First, never let a find-and-replace or a text-replacement rule turn --> into → inside a fence — you will get a diagram that fails to parse, with no clue in the error about where the character came from. Second, because a fenced code block suppresses character-reference decoding, an entity name written inside a Mermaid fence is not resolved by the markdown parser. Whether Mermaid itself does anything with it at render time is a separate question I have not tested; if you want a Unicode arrow in a node label, paste the character.

How Do You Preview Markdown Arrows on a Mac?

macOS ships no markdown renderer, so a .md file full of → opens in TextEdit as a wall of ampersands. To see what the arrows will actually look like you need something that parses the file.

VS Code — open the file and press Cmd+Shift+V for the built-in preview. It targets CommonMark through markdown-it, so all three arrow routes resolve.

MacMD Viewer — a native SwiftUI app that registers as the default .md handler. In version 1.5.1, raw Unicode arrows, entity names and numeric references all resolve to the same character in the app window and in the Finder QuickLook preview, because both rendering paths sit downstream of the same parse. Press Space on a file in Finder and the arrows are already there. Mermaid diagrams render in both paths too, so the "arrows as syntax" example above is live rather than theoretical, and the view live-reloads when you save from your editor. Download MacMD Viewer — $19.99, one-time.

GitHub itself — for a file already in a repository, pushing and looking at the rendered view is the ground truth for anything you will publish there.

For a ranked comparison across every option, including the free ones, see the best markdown viewer roundup.

Frequently Asked Questions

How do you make an arrow in Markdown?

There is no markdown arrow syntax. You get an arrow one of three ways: paste the raw Unicode character, write an HTML entity name such as →, or write a numeric character reference such as →. The last two are decoded by the markdown parser itself, which is why they work even in renderers that strip raw HTML.

What is the entity code for a right arrow in Markdown?

→ is the shortest name for RIGHTWARDS ARROW (U+2192). The aliases →, →, → and → produce the same character, and the numeric forms are → in decimal and → in hexadecimal. All of them need the trailing semicolon.

Why does my Markdown arrow entity show as literal text?

Two causes cover almost every case. The trailing semicolon is missing — CommonMark defines an entity reference as an ampersand plus a valid HTML5 name plus a semicolon, and no arrow name is legal without it. Or the entity sits inside a code span or a fenced code block, where the spec says character references are not recognised at all.

Is there an entity name for the emoji-style arrows like the black right arrow?

No. BLACK RIGHTWARDS ARROW (U+27A1), LEFTWARDS BLACK ARROW (U+2B05), UPWARDS BLACK ARROW (U+2B06) and DOWNWARDS BLACK ARROW (U+2B07) have no name in the WHATWG list that CommonMark treats as authoritative, and neither does ARROW POINTING RIGHTWARDS THEN CURVING UPWARDS (U+2934). Use the raw character or a numeric reference such as ➡.

Does Markdown convert -> into an arrow automatically?

No, and neither does Pandoc's smart extension, which handles curly quotes, en and em dashes and ellipses but leaves -> untouched. Typora's and Notion's own documentation contain no arrow substitution either. On macOS the reliable route is System Settings > Keyboard > Text Replacements, which works in every app using the standard text system.

Is an arrow in a Mermaid diagram the same as an arrow in Markdown text?

No. In prose an arrow is content; inside a Mermaid fence --> is syntax that declares an edge between two nodes, and rewriting it as a Unicode arrow breaks the diagram. Fenced code blocks also suppress character-reference decoding, so entity names inside a Mermaid fence are not resolved by the markdown parser.

Do arrows render in a Mac QuickLook preview of a Markdown file?

In MacMD Viewer 1.5.1 they do. Raw Unicode arrows, entity names and numeric references all resolve to the same character in the app window and in the Finder QuickLook preview, because both paths sit downstream of the same parse.