Markdown Highlight: ==text== and the <mark> Tag (2026)

TL;DR: Markdown has no highlight syntax. Two routes exist and they do not overlap. ==highlight== is a nonstandard editor extension: native in Obsidian, Bear and iA Writer, opt-in in Typora and Pandoc, ignored by GitHub and GitLab. <mark>text</mark> is the portable route and renders anywhere raw HTML survives the sanitizer, GitHub included. On GitHub and in MacMD Viewer, the attributes that would style it are stripped, so you get the default color and cannot choose your own.

Markdown highlight is the one piece of inline formatting that never made it into a specification. Bold, italic, strikethrough and code spans are all defined somewhere you can point at. Highlighting is not: not in CommonMark, not in GitHub Flavored Markdown, not in the original 2004 Markdown. What exists instead is a split. One syntax a handful of editors invented and agreed on, and one HTML element that works in most of the places the first one does not.

I build MacMD Viewer, a native macOS Markdown viewer, which means I spend a lot of time reading other people's renderers to find out what they do rather than what their docs claim. This guide is the result for highlighting: which apps accept ==highlight==, what GitHub's sanitizer does to <mark> (I tested it), what to use on Slack and Discord where neither route works, and why screen readers stay silent on highlighted text.

How Do You Highlight Text in Markdown?

You highlight text in Markdown one of two ways: ==highlighted text== if your editor supports the nonstandard extension, or the HTML element <mark>highlighted text</mark> if your renderer passes raw HTML through. Neither is part of any Markdown specification, so the right choice depends entirely on where the file will be read.

The decision rule is short:

• Notes apps (Obsidian, Bear, iA Writer) — use ==highlight==. It is what those apps expect, and it keeps the source readable.
• GitHub, GitLab, static sites, notebooks — use <mark>. The equals signs will show up as literal characters.
• Slack, Discord, Reddit — neither works. Jump to the fallbacks below.

The two routes converge in the end. markdown-it-mark, the plugin that adds == support to the markdown-it parser, compiles ==text== straight into <mark>text</mark>. The extension is shorthand for the element, not a separate feature.

Is ==highlight== Part of the Markdown Specification?

No. The CommonMark specification sits at version 0.31.2, released 2024-01-28, and contains no mark element, no == construct, and no highlight of any kind.

GitHub Flavored Markdown adds none either. The GFM spec header still reads "Version 0.29-gfm (2019-04-06)", and its five extensions are tables, task list items, strikethrough, autolinks and disallowed raw HTML. Not one is a highlight. The date is the useful part of that sentence: the GFM spec has not been revised since 2019, which is a checkable way of saying a highlight extension is not on its way.

The syntax was proposed to CommonMark more than once. Those threads sit open rather than formally rejected, and the recurring objection is that highlighting is presentational rather than semantic, so it belongs in HTML. Whatever you make of the argument, the practical consequence is settled: == is a per-editor opt-in, and every renderer decides for itself.

Which Apps Support ==highlight==?

Four rows in that table are routinely reported wrong elsewhere, so they are worth stating plainly.

Bear uses ==, not ::. Community posts claim Bear highlights with ::text::. Bear's own FAQ says otherwise, verbatim: "==Highlighter== : Two equals ==". If you have been typing colons, that is why nothing happened.

iA Writer supports it. I checked this one specifically because I expected the opposite from a minimalist editor. Its Markdown guide says plainly that you use double equals signs to highlight text.

Typora needs a toggle first. The docs are explicit: "To use this feature, please enable it first in the Markdown tab of the preference panel." Saying "Typora supports ==" without the qualifier will send someone hunting for a bug in their syntax.

Pandoc is the nuanced one. Pandoc has an extension named mark, added in version 3.0 (2023-01-18), and its manual documents == under that extension. But mark lives under the manual's "Non-default extensions" heading, so it is off unless you ask for it with +mark. Separately, Pandoc's own recommended way to highlight is not == at all. Its Highlighting section points at the mark class, written [Mark]{.mark} with bracketed_spans enabled. That is why Quarto, which is built on Pandoc, documents the bracketed form rather than the equals signs.

How Do You Use the <mark> Tag in Markdown?

Write the HTML element inline, exactly as you would in a web page. Markdown parsers pass raw inline HTML through to the output, so the tag survives wherever the renderer allows HTML at all. It is the same passthrough trick used for underline, which Markdown also lacks natively.

The deploy failed because <mark>the API key had expired</mark>, not because of the migration.

That produces the element unchanged in the HTML output:

<p>The deploy failed because <mark>the API key had expired</mark>, not because of the migration.</p>

MDN defines <mark> as "text which is marked or highlighted for reference or notation purposes due to the marked passage's relevance in the enclosing context." Two uses are documented: marking a passage inside a <q> or <blockquote> that was not marked in the original source, and marking content relevant to what the reader is currently doing, the way search results highlight the matched term. MDN's own analogy is a highlighter pen used on a book.

What Happens to <mark> on GitHub?

It renders, and the attributes that would style it are thrown away. I ran this through GitHub's Markdown API (POST /markdown with mode=gfm), which is the same pipeline that renders READMEs and issues, rather than inferring it from documentation:

<mark>marked</mark> then ==equals== then **bold** then <span style="background:yellow">styled</span>

The response, verbatim:

<p><mark>marked</mark> then ==equals== then <strong>bold</strong> then <span>styled</span></p>

Three facts fall out of one request. <mark> survives intact. ==equals== comes back as literal text, confirming GitHub has no highlight extension. And <span style="background:yellow"> returns as a bare <span>, with the style attribute gone. On GitHub you get <mark>'s default color and you cannot choose your own. That is the practical takeaway most guides skip.

You can reproduce it in one command:

gh api --method POST /markdown -f mode=gfm \
  -f text='<mark>marked</mark> and ==equals=='

It helps to keep two mechanisms separate here, because they are often conflated. GFM's disallowed-raw-HTML extension filters a fixed list of nine tags (title, textarea, style, xmp, iframe, noembed, noframes, script, plaintext), and mark is not among them. Separately, GitHub runs a production sanitizer on top, whose allowlist also includes mark. That sanitizer is selective rather than total: style and class are dropped, which is why colors disappear, while title survives untouched and id survives rewritten to user-content-. The spec extension explains why mark is not blocked outright; the sanitizer explains why your colors disappear. Only the second one is what you actually hit.

Markdown Highlight Support by Platform

One caveat on the GitLab row. I have not run the same live test there, and its docs point at html-pipeline's SanitizationFilter rather than printing a tag list of their own. That filter's allowlist does contain mark, so the documented behavior is that it renders. I would still test it on your own instance before relying on it in a template.

What Do You Use When Highlighting Is Not Supported?

On Slack, Discord, Reddit, or any renderer that strips HTML, no highlight exists in any form. Three universal substitutes cover almost every case, in rough order of how often they are the right answer:

• Bold — **text**. Works everywhere, and honestly the correct default. If the point is "look here", bold already says it. The bold syntax guide covers the marker rules.
• Inline code — `text`. Also universal, and visually the closest thing to a highlight because most renderers give code spans a background tint. Best for short strings, wrong for full sentences.
• Blockquote — > text. Pulls a whole passage out of the flow instead of marking a phrase inside it.

On GitHub specifically there is a better option than all three: alert blockquotes. Five types exist ([!NOTE], [!TIP], [!IMPORTANT], [!WARNING], [!CAUTION]), written as a blockquote whose first line is the type:

> [!IMPORTANT]
> The migration must run before the deploy, not after.

GitHub renders these with a colored border, an icon and a heading. They are GitHub-only, but where they work they carry far more signal than a highlighted phrase.

Is <mark> Accessible to Screen Readers?

Mostly not, and this is the argument against leaning on highlights to carry meaning. MDN is blunt about it: "The presence of the mark element is not announced by most screen reading technology in its default configuration." The element also has no implicit ARIA role. MDN lists it as having no corresponding role, so it is not exposed to assistive technology as anything in particular.

If a highlight is decorative, that silence is fine. If it carries meaning your reader would lose, MDN's documented mitigation is visually hidden text generated by CSS:

mark::before,
mark::after {
  clip-path: inset(100%);
  clip: rect(1px, 1px, 1px, 1px);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}
 
mark::before { content: " [highlight start] "; }
mark::after  { content: " [highlight end] "; }

MDN pairs that with a warning worth repeating: some screen reader users deliberately disable announcements that add verbosity, so the technique should only be applied where not knowing the text is highlighted would genuinely hurt comprehension. Highlighting half a document defeats it either way.

How MacMD Viewer Handles Markdown Highlight

MacMD Viewer renders <mark>, in the main window and in QuickLook. The tag is allowlisted in both rendering paths, so a highlighted passage looks the same whether you open the file or hit space on it in Finder.

It does not support ==highlight==. The app parses with swift-markdown, Apple's CommonMark implementation, which has no highlight extension, so ==text== comes through as literal equals signs. That is the same result you get on GitHub and GitLab, and it is the reason <mark> is the safer thing to write if your notes travel between apps.

Attributes on <mark> are stripped — every one of them, where GitHub keeps a few harmless ones — so <mark style="background: pink"> renders as a plain highlight using the default styling rather than a color you picked. That convergence is the practical rule worth taking away from this whole guide: the portable highlight is a bare <mark> with no attributes. Anything you attach to it is a bet on one specific renderer.

If you keep .md files around from AI tools, repos or notes apps and want them rendered properly on macOS without opening an editor, MacMD Viewer is a one-time $19.99 purchase with no subscription. For the rest of the syntax, the Markdown cheat sheet covers every element in one page.

Frequently Asked Questions

How do you highlight text in Markdown?

Two routes, neither in the specification. Write ==highlighted text== if your editor supports the nonstandard extension: Obsidian, Bear and iA Writer do so natively, Typora and Pandoc after you enable it. Otherwise use the HTML element <mark>highlighted text</mark>, which renders anywhere raw HTML survives the sanitizer, GitHub included.

Does ==highlight== work on GitHub?

No. I tested it through GitHub's own Markdown API and ==equals== came back as literal text. GFM has five extensions (tables, task lists, strikethrough, autolinks, disallowed raw HTML), and none is a highlight. Use <mark>text</mark> on GitHub instead.

Can you change the color of a Markdown highlight?

Usually not. GitHub strips the style attribute from inline HTML, so <mark style="background:yellow"> renders in the default color. MacMD Viewer strips every attribute on <mark> for the same reason. Custom highlight colors only work where you control the CSS, such as a static site you build yourself.

Is <mark> announced by screen readers?

No. MDN states that the presence of the mark element is not announced by most screen reading technology in its default configuration, and that the element has no corresponding ARIA role. If the highlight carries meaning, add visually hidden text through CSS ::before and ::after rather than relying on the element alone.

Does Bear use ::text:: for highlighting?

No. Bear's own documentation says two equals signs: "==Highlighter== : Two equals ==". The ::text:: claim circulates widely in community posts and is wrong.

How do you highlight text in Slack, Discord, or Reddit?

You cannot, because none of the three supports ==highlight== or raw HTML. Use bold (**text**) as the general fallback, or inline code for short strings, since most renderers give code spans a background tint that reads visually like a highlight. On GitHub, alert blockquotes such as > [!NOTE] are stronger than any of these.