github-markdown-css: seven generated stylesheets you are not supposed to edit

These files are output, and edits to them get overwritten

The first line under the title is the one to read before anything else, and it says the CSS is generated and that contributions should go to a different repository, sindresorhus/generate-github-markdown-css. That repository is also what the How section points to for how the styles are produced and for the ability to generate your own. Everything in this repository is consistent with that. The tree holds seven CSS files plus an index.html, package.json, license and readme, with no stylesheet source, no templates and no build inputs. The consequence is practical rather than philosophical. If you find a rule you want changed and you edit github-markdown.css directly, your fix works until someone regenerates, and then it is silently gone. The durable change has to be made in the generator, which is a different repository and a different contribution.

Seven themes ship, and only one of them follows the system setting

The package is described as providing seven themes, and the default one behaves differently from the other six. github-markdown.css automatically switches between light and dark through a prefers-color-scheme media query. The rest are fixed: a light-only file, a dark-only file, a dark dimmed variant, a dark high contrast variant, a dark colorblind variant for Protanopia and Deuteranopia, and a light colorblind variant. So choosing a theme means choosing a file, and only one of the seven responds to the operating system. If your audience needs a dimmed or colour-adjusted dark theme, that is a static decision you make and ship, not a preference the page discovers for itself. The accessibility-oriented variants are also split into separate files rather than combined, which keeps each one small at the cost of only one being active at a time.

One class name is the entire integration

The usage instructions are short because the contract is narrow. Import the github-markdown.css file, add a markdown-body class to the container of your rendered Markdown, and set a width for it. GitHub uses a 980px width with 45px padding, and 15px padding on mobile. The bundled example shows the whole shape, including the container rule and both media queries:

<link rel="stylesheet" href="github-markdown.css">
<style>
	.markdown-body {
		box-sizing: border-box;
		min-width: 200px;
		max-width: 980px;
		margin: 0 auto;
		padding: 45px;
	}

	@media (max-width: 767px) {
		.markdown-body {
			padding: 15px;
		}
	}

	@media (prefers-color-scheme: dark) {
		body {
			background-color: #0d1117;
		}
	}
</style>
<article class="markdown-body">
	<h1>Unicorns</h1>
	<p>All the things</p>
</article>

Note what is in that example and what is not. The stylesheet is one link tag; the width, the padding and the page background are all in your own style block.

The dark page background is set outside the markdown class

Look again at where the dark background lives in that example. It is a prefers-color-scheme media query setting the background-color of body to #0d1117, and it sits alongside the markdown-body rules rather than inside them. That is deliberate scoping, and it tells you what this package does not do. The stylesheet formats the content inside the container; the page behind it is yours. So a page that imports the default auto theme and is viewed in dark mode does not get the dark page background from the stylesheet unless you also add the background rule. The same applies to the container geometry: the 980px width and the 45px and 15px padding are values the example supplies for you to copy or change, not values baked into the file you downloaded.

Dark mode tables rendering black is a doctype problem

The troubleshooting section contains the single most useful diagnostic in this repository, and it is about a document mode rather than about CSS. The guidance is that if you encounter styling issues, such as tables in dark mode rendering their fonts in black, the browser may be using quirks mode by accident, and the fix is to always include a doctype at the top of your page:

<!doctype html>
<html lang="en"><head></head><body></body></html>

The consequence for anyone debugging this is that a rendering fault which looks exactly like a stylesheet problem may have nothing to do with the stylesheet. Quirks mode changes how the browser resolves box model and table inheritance, so rules you did not write can stop applying. One line at the top of the document removes a whole category of confusing failure, and it is the first thing to check before spending time reading generated CSS you cannot meaningfully edit.

Code highlighting is deliberately somebody else's job

The package styles code blocks but does not produce the highlighting inside them, and the documentation says so directly. To mimic how GitHub highlights code, you are pointed at starry-night to use with your Markdown parser of choice. For the markup itself there are two routes. You can call GitHub's markdown API to turn Markdown into the HTML that GitHub generates, which the documentation says works well with the CSS in this repository, or you can use another parser, where the stated expectation is that other Markdown parsers will mostly work with these styles. Two consequences follow. The word mostly is doing real work in that sentence, so a parser whose output diverges from GitHub's will inherit that divergence visually. And if you take the API route for rendering, you are sending your Markdown to GitHub to get HTML back, which is a dependency decision as much as a styling one.

npm run make rebuilds all seven files through one pipeline

The development story is a single script, and the manifest shows exactly what it does. There is one generation script per theme, each invoking the generator with a no-use-fixture flag and a theme name, redirecting standard output into the matching CSS file, and a top-level make script that chains all seven in order from light through the dark variants, the colourblind pair and finally auto. Engines declare node 10 or newer. So the committed stylesheets are the end of a fixed pipeline rather than seven hand-maintained files, and a regeneration is one command that rewrites all of them. The release history reflects a project that changes rarely rather than continuously, with tags at 5.8.1 in November 2024 and 5.9.0 in February 2026, so a minor version bump arriving after more than a year is the normal cadence here rather than a sign of abandonment.

Editorial conclusion

github-markdown-css suits anyone rendering Markdown on their own site who wants it to look like GitHub without hand-writing styles, and who is content with a stylesheet scoped to a single class. It does not suit you if you need code highlighting, since that is explicitly delegated to starry-night, and it does not suit you if you intend to patch the styles, because these files are generated and contributions belong in the generator repository. Before adopting, check that your parser emits the markup these selectors expect, include a doctype, and set the page background yourself.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sindresorhus/github-markdown-css on GitHub