Color text in markdown

[jeppeutzon]

@bkeepers : FYI people are continually asking for coloured text in this closed issue:

#369

[paquinmathieu]

Hi, thank you for starting this new issue. I would absolutely appreciate that feature. Thank you

[ddopson]

+1000, which is a roughly accurate summation of six years worth of continuous +1 posts on issue #369, most of which weren't noticed due to that issue being closed for most of that time. (I'm exaggerating only slightly; the real number is 76 posts)

Please fix this and sunset one of my most popular StackOverflow questions (another +358 upvotes and counting): https://stackoverflow.com/questions/11509830/how-to-add-color-to-githubs-readme-md-file

Color is an important design feature for many CLI tools, including my underscore-cli tool for hacking on JSON data, and thus, it's important to be able to include properly colored output examples in the documentation.

Currently, the ONLY way to accomplish this is with a screenshot:

Screenshots are inferior to natively colored text. Beyond the minor inconveniences of being cumbersome to create / edit / maintain, and slower for browsers to load, screenshots thwart readers from copy/pasting key snippets of text, such as the command that was executed in the screenshot -- this makes the documentation less usable, and the potential work-arounds are all very ugly.

Another use-case from issue #369: There's a reason you support auto-colorization of code blocks --- coloring text is crucial for facilitating our eyes to parse it faster. However, there's no fallback story for tail languages and other structured text formats that aren't in your list.

Many, many projects would benefit from being able to tastefully color the structured text in their documentation.

[GiuseppeChillemi]

I am here to add my support to colorization in Markdown. Colors are an essential part of communication and we are in 2021, not in 1981 with monochrome displays.

[xinye83]

+2147483647, we need this to happen!

[aarakelian]

Please, make colors happen!

[dazdapertrakz]

It is crucial indeed! It's been 7 years for god's sake...

[avishnyakov]

One of examples where color text in markdown is useful is Terraform plan reviews.

Consider attaching Terraform plan into GitHub tickets, issues or pull requests. Having TF plan is useful, makes it easier to review pull request, but.. it is plan text, no colors at all.

[akloss-cibo]

You can abuse the support for diff. I pipe it through this function (zsh/osx):

format_plan () {
	awk '
    /Terraform will perform the following actions:/ { found=1 }
    /------------------------------------------------------------------------/ { found=0 }
    // { if (found) { print $0 } }
  ' | (
		printf '<details><summary>Plan for %s</summary>\n\n```diff\n\n' "$1" && perl -pe 's/\x1b\[[0-9;]*[mG]//g' | sed -e 's/^\(  *\)\([\+-]\)/\2\1/' -e 's/^\(  *\)~/!\1/' && printf '```\n</details>'
	) | pbcopy
}

[SiddharthShyniben]

At least, GitHub could create a custom attribute (<span data-color="red">Red</span>) for example. This would be great as you don't have to use style attributes anymore anymore. It would be easy to style these with some javascript.

Recap of two hacks methods provided to do this

Images

![Red text](http://placehold.it/size/background-hex/foreground-hex?text=a123)

Diffs

```diff
+ Green
- Red
! Orange
@@ Pink @@
# Gray
...

It's okay but no inline text I guess

And we also have those symbols. but we can disguise them by doing + Green + instead of + Green for example

[Rikj000]

Idk what GitHub is waiting for, all IDE's I use support coloring in MarkDown..
The hacks described above "work", but should really not be considered as a "fix". The solution is way too dirty for that...
It's 2021 guys, we'd like some proper

+ C +
- O -
! L !
@@ O @@
# R #
S

please! 🙏

[AjayChambers]

Damn, I am surprised at how many people have been asking for color to be implemented into the GitHub markdown preview, and how long they have been asking for it w/o reply. When a company is new, they are so quick to cater to a customers needs, but when they get big like GitHub did, they can honestly care less. Its not that I think they should insert color into there markdown engine, but at the very least give a quick one liner reason as to why they won't implement color into MD rendering engine.

If I had to guess as to why they don't implement color, I would say it is because, they are the only one with black and white text & oversized headers. There markdown, generates a README view that is unique onto GitHub. Any of us can look at a dot MD document on GitHub, and know we are reading something in a GitHub repository. It is so unique and custom, that I see editor extensions that generate markdown in the same format as GitHub does. There MarkDown is a unique trademark of there site. Which makes since because I know that, (75% ) or more, of the time I spend in GitHub, is in my own, or someone else's, README.md documents. I believe they are MS now, which are like the contemporary marketing gurus.

EDIT:
Just wanted to point out that using something like
+ some-text +
- some-text -
# some-text #
* some-text *

wont work because most of the syntax you are suggesting is already being implemented in Markdown. You need something unused
like:

$[1] SumText $

Where 1 equals a set of numbers ex(1-8) or (1-4) or whatever...
each number is a different color. It would take some ingenuity to implement. Many of the commonly used shorthand's are alreadt being implemented in contemporary markdown.

[Fabrizio-Caruso]

Could you please some support for colored text in markdown?

[4renginy]

Yes color is important part of communication particularly if you are working on visual components. Please make it possible.

[gomain]

Yes, colors please.

[emiltin]

colors would be useful when discussing e.g. the output of RSpec, which uses colors a lot.

[AjayChambers]

Gosh Darn it GitHub, life is no fun without color! Please don't make us read black & white documentation for another 5 years. Give us something to zest our README docs up with. GitHub Markdown feels very archaic, quite honestly, visiting a GitHub README.md doc reminds me of watching I Luv Lucy, except I Luv Lucy was funny at least! Or, actually i just remembered that I Luv Lucy Wasn't funny, but you get the point. GitHub Docs needs color, please give us color, so GitHub stops looking like a 1950's throwback website from an alternate reality where the internet was invented 50 years earlier.

[LauDijksterhuis]

Doesn't have to be HTML tags, you are industry leaders if you think some other option is better. Just set the standard, I'm sure everyone is happy as long as we get colors 😃

[CelDaemon]

maybe a custom extension to the markup language, that makes it possible to use different colors for light/dark/dimmed mode

[alexey-milovidov]

I need gray colored text to quickly differentiate from author's text and text left in issue/pull request template.
Example: ClickHouse/ClickHouse#26897

The text

By adding documentation, you'll allow users to try your new feature immediately, not when someone else will have time to document it later. Documentation is necessary for all features that affect user experience in any way. You can add brief documentation draft above, or add documentation right into your patch as Markdown files in docs folder.

has to have gray color.

PS. Maybe I will simply use quotation for that purpose.

[asherhe]

It's already 2021 and Github still insists on ignoring colors.

Why

[ChicagoGupta]

give me colors or give me death

[chanukov]

This makes me so sad that a feature which is one of the most basic features in any IDE/ is getting no love from Microsoft/github...

[simon-guider]

+1

[San3-Cod3]

On the airflow helm chart repo I use emoji to add color. Specifically the solid colors (because they are consistently represented across devices) along with quote blocks.

Examples (Demo)

🟦 Tip 🟦
My helpful tip!

🟨 Note 🟨
My informative note.

🟥 Warning 🟥
My scary warning!

# you can add code blocks in quotes too!
print("Hello World!")

Examples (Code)

> 🟦 __Tip__ 🟦
>
> My helpful tip!

> 🟨 __Note__ 🟨
>
> My informative note.

> 🟥 __Warning__ 🟥
>
> My scary warning!
>
> ```python
> # you can add code blocks in quotes too!
> print("Hello World!")
> ```

Emoji Reference

Squares

🟥 Red Square 🟧 Orange Square 🟨 Yellow Square 🟩 Green Square 🟦 Blue Square 🟪 Purple Square 🟫 Brown Square ⬛ Black Large Square ⬜ White Large Square

Circles

🔴 Red Circle 🟠 Orange Circle 🟡 Yellow Circle 🟢 Green Circle 🔵 Blue Circle 🟣 Purple Circle 🟤 Brown Circle ⚫ Black Circle ⚪ White Circle

Hearts

❤️ Red Heart 🧡 Orange Heart 💛 Yellow Heart 💚 Green Heart 💙 Blue Heart 💜 Purple Heart 🤎 Brown Heart 🖤 Black Heart 🤍 White Heart

Diamonds

🔶 Large Orange Diamond 🔷 Large Blue Diamond 🔸 Small Orange Diamond 🔹 Small Blue Diamond 🔺 Red Triangle Pointed Up 🔻 Red Triangle Pointed Down

This, among other recent removals, a lot of workarounds we had to use colour in any such capacity on the site are slowly being phased out or broken completely until we have a slither of nothing.

[plan44]

I found this thread while searching for MD syntax extensions for colorizing. I also wish github would implement one, but for the time being I hacked the MD renderer I use for my website with the following syntax:

_(red)this text will be rendered in red_

This is the most source readable and writable annotation I could find so far.

Reading the above comment, a further improvement could be detecting those color emojs such that the color would be immediately apparent in plain text source:

_(🟦)this text will be rendered in blue_

I'd happy to hear better ideas about how a native MD coloring syntax could look like!

[dylan-tock]

I found this thread while searching for MD syntax extensions for colorizing. I also wish github would implement one, but for the time being I hacked the MD renderer I use for my website with the following syntax:
[...]
I'd happy to hear better ideas about how a native MD coloring syntax could look like!

I don't think it's ever been an issue of "how can this be done from a coding standpoint". From what @dipree said just over 2 years ago, the idea of having documentation colors (which users would control) clashing with themes (whose palettes are determined by GH folks) is something he/they did not want at the time of that post. In a later post, @dipree indicated there were two issues:

• coloring based on semantic payload (my paraphrase). Three new options (==highlight==, ++positive++, and --negative--) were suggested as possibilities that were being explored at the time.
• coloring used for custom syntax highlighting. This was separate from semantic-based coloring and "[They were] considering that separately." ¹

So, it's not a question of ability to make the change, it's a question of desire or will to make the change.

Footnotes

1. @dipree Is there a publicly viewable issue for the consideration being done on this? Also, has there been any movement on the consideration on this topic? ↩

[paquinmathieu]

@San3-Cod3 they are not consistently represented. I can see the other emojis but not the squares.

[luigiMinardi]

they are not consistently represented. I can see the other emojis but not the squares.

Are you on Linux? If so, you're probably missing some emoji font package.

[darioarias]

color please!

[MarvinJWendt]

Manually coloring text would not be accessible to people with impaired vision, as the GitHub color schema can be changed via themes. Just because a color looks good on a dark background, does not mean that it looks good on a light or high contrast background.

For that reason, I propose that there are a couple usable colors. Maybe the same as in ANSI?

```color
[red]Some red text[/red]
{green}Some text with green background{/green}
```

That way, those colors could be depending on the selected user theme. (Like in a terminal!)

This would also allow putting syntax highlighting into markdown blocks, which use a language that is not supported by GitHub. Maybe the repo is a game engine that has its own scripting language, or something like that.

If custom hex codes are still needed, they could be implemented like that:

```color
[#ff0000]Some red text[/#ff0000]
{#00ff00}Some text with green background{/#00ff00}
```

[Hapaxia]

$\textsf{{\color[rgb]{0.0, 0.0, 1.0}W}{\color[rgb]{0.1, 0.0, 0.9}e~ }{\color[rgb]{0.2, 0.0, 0.8}c}{\color[rgb]{0.3, 0.0, 0.7}a}{\color[rgb]{0.4, 0.0, 0.6}n~ }{\color[rgb]{0.5, 0.0, 0.5}c}{\color[rgb]{0.6, 0.0, 0.4}o}{\color[rgb]{0.7, 0.0, 0.3}l}{\color[rgb]{0.8, 0.0, 0.2}o}{\color[rgb]{0.9, 0.0, 0.1}u}{\color[rgb]{1.0, 0.0, 0.0}r}}$ text already; that's the not the issue.
It's that it's not selectable or searchable and that harms accessibility.

[michael-lehn]

It really sucks that GitHub does not care. Allowing <span style="color:blue"> would provide a way for manually syntax highlighting code. Very valuable when you want to design your own language.

Seems GitLab does allow it. So the solution is called https://gitlab.com

Since my Apple //e days I have a strong antipathy for anything Microsoft related. Now I remember way. They just don't have style. And they don't care about users.

[Lainezs]

Duplica

[Neustradamus]

It is an important missing feature...

[Rudxain]

+2147483647, we need this to happen!

upvote += 0b10n ** 0x40n

[syntax-tm]

Years later and we still can't color text in Markdown. I had to resort to HTML in two different SVG images, one for the light theme and one for the dark theme. As everyone has already pointed out this isn't a great solution, since you can't select the text or search for it (unless you're searching the DOM).

We're halfway through 2024. We have Mermaid charts with support for their own custom CSS styling. We can load different images based on the current user's theme. Yet we still can't color plain text. This is probably my biggest complaint with the GitHub markdown and has been for a while now.

I'm guessing that it's just not a priority but if there's concern for people obscuring text or whatever then give us a predefined set of colors for the foreground (the background would be nice too, but foreground is priority). You can ensure they look good with the current GitHub themes and that would cover a majority of use cases for most people. Just add the 8 basic ANSI color codes as a first step.

It's sad to think that cmd.exe has better text styling than GitHub...

[Hapaxia]

Years later and we still can't color text in Markdown. I had to resort to [HTML in two different SVG images]

There is not much need for $\textsf{\color[rgb]{1.0, 0.0, 0.0}SVG}$ images when you can just use $\textsf{\color[rgb]{0.0, 1.0, 0.0}inline code}$ to create coloured text.

There is not much need for $\textsf{\color[rgb]{1.0, 0.0, 0.0}SVG}$ images when you can just use $\textsf{\color[rgb]{0.0, 1.0, 0.0}inline code}$ to create coloured text.

So... we have the ability but it's limited in its accessibility.

[syntax-tm]

Years later and we still can't color text in Markdown. I had to resort to HTML in two different SVG images

There is not much need for SVG images when you can just use inline code to create coloured text.

There is not much need for $\textsf{\color[rgb]{1.0, 0.0, 0.0}SVG}$ images when you can just use $\textsf{\color[rgb]{0.0, 1.0, 0.0}inline code}$ to create coloured text.

So... we have the ability but it's limited in its accessibility.

Wrong.

We do not have the ability. The good news is that your response has annoyed me enough to explain why you're wrong.

Note

Keep in mind this isn't an all-inclusive list but rather a select few points to support the claim.

Searching and Selecting Text

You cannot select or search for the text. In fact, you can't even search for a single character let alone multiple.

Text Overflow

Math expressions do not wrap properly if the width overflows.

$\textsf{\color[rgb]{1.0, 0.0, 0.0}ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789}$

You know what does wrap properly if it overflows? Text.

ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

Can you color that? ❌
So do we have the ability to create colored text? ❌

GitHub Markdown Support vs. Third-Party Feature

There's a huge difference between GitHub's markdown supporting something and a third-party library they're using supporting it.

Maybe one day MathJax decides to remove it for whatever reason (nobody uses it, annoying to maintain it, etc.) or the project is abandoned. What's GitHub supposed to do, stay on that out-of-date version? What if there's a vulnerability that's discovered?

Other "Solutions"

Can you set the color of some text in a math expression? Sure. I can also set the color of the text in this gold star image.

Whether you set the "color of the text in a math expression" or "color of the text in an image" the result is the same, a non-text element(s).

Text Is Quotable, Math Expressions Are Not

You probably noticed this already at the top but you can't quote that math expression.

So much for that "colored text" you were talking about.

On the plus side, you can quote an SVG.

Conclusion

Do we have the ability to color text in GitHub markdown? No. For all the reasons I mentioned above, and the countless others I didn't mention, we do not have the ability to color text.

Note

Apologies to everyone else for this notification.

[plan44]

Apart from the excellent reasons @syntax-tm mentioned, anything that requires that much markup to add a color attribute is useless for me as a writer of MD docs. The ingenious thing that makes MD such a success is that the source code remains readable, because the markup is so simple and aligned with what one would do (and did, in the past) having only a single font typewriter, to structure and emphasize text.

Regarding the conflict between theming and colors raised by some comments above: I see two pretty separate uses of "colors":

1. As an extra attribute to create structure. For example, when I am explaining a complex command line with many options, and want to describe which part of it means what, I'd use colors to mark the parts, and corresponding explanatory text nearby.
   For that, it is largely irrelevant what actual colors these marks have. A small set of (e.g. 8) marker "colors" that may render different in different themes would suffice for that purpose. Accessibility fallbacks using another visual hint than actual color would work as well. However I know nothing as easy to understand at the first glance as color coding. I guess I am not alone, because syntax coloring is a thing.
   Speaking of syntax coloring - this kind of marking would be even more useful when it was available within code blocks. I understand that this would bring some extra technical challenges around escaping though...

2. As a stylistic attribute to make things look better, nicer by actually applying very specifically chosen actual colors. I'm pretty sure this does not belong into the Markdown domain - because all of markdown is about content, not styling.

Bottom line: in the Markdown domain, maybe we should not demand "colors", but a set of text labelling attributes for which an obvious and easy to understand standard rendering choice would be color in most cases, but still allow alignment with theme design and alternative representations for accessibility reasons.

[github-actions]

Stale issue message

[cwellsx]

BTW I only just found -- you probably know already -- that:

• You can output markdown to GitHub Pages
• That conversion to HTML is typically done via Jekyll -- which supports other implementations of markdown
• These other versions of markdown support colors and more

Documentation which uses that, and a tool-setup to publish that, includes for example https://just-the-docs.com/

[Hapaxia]

So... we have the ability but it's limited in its accessibility.

Wrong.

We do not have the ability. The good news is that your response has annoyed me enough to explain why you're wrong.

I appreciate your reply and I'm glad that my response is making people think about this issue but I am sorry that it annoyed you.

It should be noted, though, that I completely agree with you. The point I was making there (and in my earlier post) is just what you mentioned: it's not usable as interactive text e.g. selectable and searchable. This, by the way, is what I meant by the word accessibility.

Remember that just because it is limited in its accessibility (in the ways just mentioned) doesn't mean that it is not text. Text can be included in an image and it is still text. This ability we have; we can create "coloured text" but it's akin to it being an image, just created inline.

This is the issue and the one that should be addressed here. Not providing an ability to "do it properly" will force people who want to control the colour of their text to use images (or inline code to generate similar) and this severely harms accessibility so just providing a way to do it would allow colour to be added to text without resorting to images etc. and would keep text useable and accessible.

[R4ygen]

+1

Implement this basic function already please, instead of forcing users to find hacky ways to implement it themselfes every time.

[Zi7ar21]

I would like ANSI colored text in code blocks, i.e.

```ansi
[ANSI-formatted text with color escape codes]
```

which allows for pasting of ANSI terminal output, as one might obtain on Linux with

unbuffer <command with ANSI output> | xclip

I know Discord's Markdown has this feature. It's handy for when programs have colored output that makes it easier to find important details, such as errors, which is something GitHub is supposed to specialize in (software development)...