Visual Studio Code themes are the most-installed category in the entire Marketplace — and the least examined. Almost every guide online shows the same ten popular themes, explains how to click “Install”, and stops exactly where it gets interesting.
This article does it differently. We didn’t research, we measured: we counted the complete Themes category of the Marketplace (18,420 extensions), downloaded the 60 most-installed ones, unpacked them and pushed 302 colour themes through a WCAG contrast calculator. Then we built our own theme and systematically tried to break it.
Two findings up front, and both contradict what you usually read:
First: In 86% of the themes we measured, the comment colour has less contrast than the WCAG guideline requires for normal text. The median sits at 2.95 — 4.5 would be needed. This doesn’t affect obscure niche products, but the most widely used themes there are.
Second: Themes that carry “High Contrast” in their name are not exempt. 18 out of 21 fail. One of them measures 2.59 on editor text — less than the 3.0 that wouldn’t even suffice for large type.
The short version
| Question | Answer (measured 2 Sep 2026) |
|---|---|
| How many VS Code themes exist? | 18,420 in the “Themes” category |
| For comparison: all extensions | 135,526 |
| Share of installs held by the top 50 | 73.4% of 375M |
| Median installs per theme | 377 |
| Themes with zero installs | 654 (3.6%) |
| Not updated in over 2 years | 65.6% |
| How big is a theme of your own? | Ours: 2,124 bytes |
| How many colour keys does VS Code know? | 843 (counted from source) |
| Median colour keys used per theme | 237 |
| Comment contrast below WCAG AA (4.5) | 86% of themes |
Does vsce validate colour values? | No — not one of our 5 defects was caught |
/_apis/public/gallery/extensionquery), category “Themes”, 197 pages of 100 entries, deduplicated to unique extension IDs. The 60 most-installed were downloaded as VSIX, unpacked, and their package.json plus all referenced theme files evaluated. Contrast calculated per WCAG 2.1 (relative luminance); alpha values were composited against the respective editor background rather than discarded. Colour keys counted from src/vs/platform/theme/ in microsoft/vscode (as of 1.137.0). vsce 3.9.2.
What a VS Code theme technically is
A theme is an extension without code. It has the same packaging as any other VS Code extension — a ZIP archive with a package.json — except that instead of JavaScript, it contains nothing but colour definitions.
VS Code distinguishes three kinds that are frequently confused:
- Colour themes (
contributes.themes) recolour the editor and interface. This is what people mean by “themes”. - File icon themes (
contributes.iconThemes) swap the symbols in the file tree. They contain not a single colour for the editor. - Product icon themes (
contributes.productIconThemes) replace the interface’s own icons — the gear, the magnifier, the debug arrow.
This distinction isn’t pedantry, because it explains an oddity in the rankings. Among the 25 most-installed entries in the Themes category, six are pure icon packages that set no colours at all — including positions 2 and 3.

And the number one spot is stranger still. Leading the Themes category with 58.9 million installs is ms-vscode.cpptools-themes — a companion package to the C/C++ extension that ships four Visual Studio colour schemes and hasn’t been updated since October 2022. Hardly anyone installs it deliberately; it arrives as a dependency.
The ranking doesn’t measure what you think
At position 10 of the Themes category sits a package called “No Code” with 5.8 million installs. Its description: “No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere.”
We unpacked it. Its contributes object is literally empty:
"contributes": {}
It contains no theme, no colour, no functionality — just a README.md and an image. It appears in the Themes category because its package.json lists itself under all 15 categories at once: Azure, Data Science, Debuggers, Formatters, Keymaps, Snippets, Themes and so on.
🔑 This is the first finding, and it has consequences for every “Top 10 Themes” list online: Category assignment in the Marketplace is a self-declaration by the author, not a verification. Anyone copying the rankings unfiltered ends up recommending a compiler add-on, six icon sets and a joke — which together occupy thirteen of the top 25 slots.
For this article we therefore opened every package and checked whether contributes.themes was present at all, instead of trusting the category.
How many themes really exist — and how few get used
The “Themes” category reports 19,679 hits. After removing pagination duplicates, 18,420 unique extensions remain, from 15,179 different publishers.
That number is often used as an argument: “huge selection”. As a quality indicator it’s worthless, and that can be demonstrated.
| Threshold | Themes below | Share |
|---|---|---|
| 0 installs | 654 | 3.6% |
| under 10 | 1,085 | 5.9% |
| under 100 | 4,867 | 26.4% |
| under 1,000 | 12,217 | 66.3% |
| under 10,000 | 17,016 | 92.4% |
| under 100,000 | 18,167 | 98.6% |
install statistic reported by the Marketplace.
The median is 377 installs. Two thirds of all themes have fewer than a thousand. At the same time, 73.4% of all 375 million installs go to the top 50, and 90.4% to the top 500.

Put differently: of 18,420 themes, roughly 500 matter and the rest is statistical noise. Page far enough through the rankings and from around rank 15,000 you find entries with single-digit install counts and names that have nothing to do with code editors — our samples turned up Letempsdessecrets-vostfr-en-streaming and stellar-taiwan-online. The Marketplace is being abused as a streaming directory, and the Themes category is apparently a favourite dumping ground.
Two thirds have stalled
More telling than the install count is the date of last update. We read lastUpdated for every entry:
- Median age: 1,170 days — more than three years.
- 65.6% haven’t been touched in over two years.
- 39.4% haven’t been touched in over four.
For a theme this is less dramatic than for an extension with code — a theme can’t really “break”. But it ages anyway, in a way you don’t immediately see: VS Code continuously introduces new colour keys. A theme from 2021 simply doesn’t know the keys for newer interface parts, so the default colour takes over there. The result is regions that look off — the most common reason a theme feels “somehow unfinished”.
The test nobody runs: contrast
This is where it gets serious. A theme isn’t a decorative object — it’s the surface developers stare at eight hours a day. Whether text on it is readable can be measured objectively: the WCAG guideline defines a contrast ratio between foreground and background. 4.5 is the minimum for normal text (level AA), 7.0 for the stricter level AAA. Below 3.0 is insufficient even for large type.
From the 60 downloaded packages we extracted all 302 colour themes and calculated for each:
- the contrast of
editor.foregroundagainsteditor.background, - and the contrast of the three most-read token types: comments, strings and keywords.
289 themes could be fully evaluated (6 files had malformed JSON, 2 set no editor background at all). The result:
| Measured | Median | Minimum | below 4.5 (AA) |
|---|---|---|---|
| Editor text on background | 10.79 | 2.48 | 5 (2%) |
| Comments | 2.95 | 1.60 | 248 (86%) |
| Strings | 5.97 | 1.60 | 129 (45%) |
| Keywords | 5.79 | 2.19 | 75 (26%) |
tokenColors entry for the scopes comment, string and keyword; colours with an alpha channel were composited against the editor background rather than discarded. n = 289 themes from 44 packages.
🔑 The central finding: body text is fine almost everywhere, comments are fine almost nowhere. In 86% of themes the comment colour falls below the AA threshold, and in 147 themes below even 3.0.

This isn’t accidental, it’s deliberate — which is exactly what makes it debatable. Theme designers mute comments so they don’t compete with the code. The reasoning: comments are “secondary”. Except that assumption stops holding the moment someone reads unfamiliar code and needs precisely the explanations. Or has impaired vision. Or is sitting with a laptop in daylight.
You can consider this design decision defensible. But you should know it was made — and it appears nowhere in the Marketplace descriptions.
“High Contrast” in the name means nothing
The most striking single finding of our measurements. We filtered out every theme carrying “High Contrast” or “HC” in its name — precisely the ones you would pick if readability were the problem. 21 of them. Of those, 18 fail on comment contrast, all 18 below 3.0:
| Theme | Editor text | Comment |
|---|---|---|
| Bearded Theme HC Chocolate Espresso | 7.67 | 1.67 |
| Material Theme Darker High Contrast | 15.63 | 1.82 |
| Community Material Theme Darker High Contrast | 15.63 | 1.82 |
| Material Theme Ocean High Contrast | 10.26 | 2.17 |
| Bearded Theme HC Flurry | 13.05 | 2.18 |
| Material Theme High Contrast | 12.77 | 2.44 |
| Material Theme Lighter High Contrast | 2.59 | 2.59 |
| GitHub Light High Contrast | 18.91 | 5.04 ✅ |
| GitHub Dark High Contrast | 17.57 | 11.12 ✅ |
The case of Material Theme Lighter High Contrast is the most extreme, so we recalculated it by hand rather than trusting the script. The values from the theme file:
editor.background = #FFFFFF
editor.foreground = #90A4AE
A mid blue-grey on white. That works out to 2.59 — not even the 3.0 that would suffice for large type. A theme called “High Contrast” holds the lowest base contrast in our entire measurement series.
🔑 The rule that follows: a theme’s name is marketing, not a measurement. And this can’t be waved away as a matter of taste — “High Contrast” isn’t a style label, it’s an accessibility promise. Here it’s broken, with nothing anywhere to contradict it.
The positive counter-check: GitHub Dark High Contrast delivers what the name says — 17.57 on editor text and 11.12 on comments, comfortably above AAA. So it’s achievable. It just isn’t verified.
Incidentally, the uiTheme field offers no protection either. It accepts the values hc-black and hc-light for genuine accessibility themes. 16 themes in our series declare this — and 13 of them still fall below 4.5 on comment contrast.
How popular themes score
So this doesn’t stay abstract, here are the figures for the best-known themes, measured against the same criteria.
| Theme | Editor text | Comment | String | Keyword |
|---|---|---|---|---|
| GitHub Dark Default | 16.02 | 6.15 ✅ | 6.15 | 7.51 |
| Winter is Coming (Dark Blue) | 12.33 | 6.44 ✅ | 17.80 | 8.57 |
| Shades of Purple (Super Dark) | 17.29 | 5.03 ✅ | 14.25 | 11.60 |
| GitHub Light Default | 15.80 | 4.55 ✅ | 4.55 | 5.36 |
| Dracula At Night | 17.39 | 3.94 | 7.77 | 7.68 |
| Night Owl | 13.54 | 3.87 | 11.22 | 7.62 |
| One Dark Pro | 6.57 | 3.73 | 6.94 | 4.75 |
| Cobalt2 | 12.75 | 3.62 | 10.51 | 6.12 |
| Ayu Dark | 10.12 | 3.25 | 11.54 | 8.39 |
| Dracula Theme | 13.36 | 3.03 | 5.97 | 5.90 |
| Monokai Pro | 13.79 | 2.88 | 2.88 | 4.94 |
| Tokyo Night | 8.10 | 2.50 | 2.50 | 2.93 |
| Atom One Dark | 6.57 | 2.32 | 6.94 | 4.75 |
| Ayu Light | 5.93 | 2.10 | 2.35 | 2.35 |
| Min Light | 16.10 | 1.76 | 7.72 | 14.67 |
Two observations:
Light themes aren’t automatically better. The common reflex “light = more readable” doesn’t survive measurement: for dark themes the median comment contrast is 3.05, for light themes 2.83. The share below AA is only slightly lower for light themes (76% versus 89%).
A high base contrast saves nothing. Min Light has an excellent editor contrast of 16.10 and, at 1.76, one of the worst comment values anywhere. Checking only the main colour misses exactly this.
Building your own: the shortest complete guide
The best way to get a theme that meets your own requirements is to write it yourself. The effort is far smaller than most assume — our complete, packageable theme is 2,124 bytes and consists of two files.
Step 1: package.json
{
"name": "getmind-nord-test",
"displayName": "GetMind Test Theme",
"description": "A theme with measured contrast values",
"version": "0.0.1",
"publisher": "getmind",
"engines": { "vscode": "^1.90.0" },
"categories": ["Themes"],
"contributes": {
"themes": [
{
"label": "GetMind Dark",
"uiTheme": "vs-dark",
"path": "./themes/getmind-dark.json"
}
]
}
}
Three fields here are not optional, and vsce aborts without them: engines.vscode, a valid version, and publisher. uiTheme accepts four values — vs (light), vs-dark (dark), hc-black and hc-light (accessibility). It controls the default colours for everything the theme doesn’t set itself.
Step 2: the theme file
{
"name": "GetMind Dark",
"type": "dark",
"colors": {
"editor.background": "#1B2028",
"editor.foreground": "#D8DEE9",
"editorLineNumber.foreground": "#6B7689",
"editor.selectionBackground": "#39404D",
"editorCursor.foreground": "#88C0D0",
"sideBar.background": "#161A21",
"activityBar.background": "#161A21",
"statusBar.background": "#2E3440"
},
"tokenColors": [
{ "scope": ["comment"],
"settings": { "foreground": "#8B95A7", "fontStyle": "italic" } },
{ "scope": ["string"],
"settings": { "foreground": "#A3BE8C" } },
{ "scope": ["keyword", "storage.type"],
"settings": { "foreground": "#81A1C1" } },
{ "scope": ["entity.name.function"],
"settings": { "foreground": "#88C0D0" } },
{ "scope": ["constant.numeric"],
"settings": { "foreground": "#B48EAD" } }
]
}
That’s all of it. No build process, no framework, not a line of JavaScript.
The crucial part is the two-way split that trips many people up: colors paints the interface (editor background, sidebar, status bar) using fixed keys. tokenColors paints the source code itself using TextMate scopes like comment or entity.name.function. If a colour seems to be missing, you’re usually looking in the wrong one of the two blocks.
How many colour keys are there really?
This figure circulates in every conceivable variant, so we counted it in the source rather than copying it. In microsoft/vscode (as of 1.137.0), the code registers 964 calls to registerColor() across the whole src tree, yielding 843 unique colour IDs.
You don’t need all of them. The median across our 289 measured themes is 237 colour keys set, the minimum 22, the maximum 605. Anything unset falls back to the default of the chosen uiTheme.
For tokenColors the spread is wider still: median 55 rules, minimum 12, maximum 951.
Step 3: check the colours before anyone uses them
This is the step the 86% in our series skipped. Contrast can be calculated in a few lines — here in Python so it runs without dependencies:
def luminance(hexcolor):
h = hexcolor.lstrip('#')
r, g, b = [int(h[i:i+2], 16) / 255 for i in (0, 2, 4)]
f = lambda v: v/12.92 if v <= 0.03928 else ((v+0.055)/1.055) ** 2.4
return 0.2126*f(r) + 0.7152*f(g) + 0.0722*f(b)
def contrast(fg, bg):
a, b = luminance(fg), luminance(bg)
light, dark = max(a, b), min(a, b)
return (light + 0.05) / (dark + 0.05)
bg = '#1B2028'
for name, colour in [('Text', '#D8DEE9'), ('Comment', '#8B95A7'),
('String', '#A3BE8C'), ('Keyword', '#81A1C1')]:
print(f'{name:10} {contrast(colour, bg):.2f}')
For our theme that yields:
| Element | Colour | Contrast | AA (4.5) |
|---|---|---|---|
| Editor text | #D8DEE9 | 12.11 | ✅ |
| Comment | #8B95A7 | 5.42 | ✅ |
| String | #A3BE8C | 8.02 | ✅ |
| Keyword | #81A1C1 | 6.08 | ✅ |
| Function | #88C0D0 | 8.18 | ✅ |
| Number | #B48EAD | 5.77 | ✅ |
| Line number | #6B7689 | 3.57 | ⚠️ |
The line number sits deliberately below 4.5 and we’re leaving it there, with a justification: it’s a pure orientation element, not body text, and it stays above the 3.0 threshold for UI components. The difference from the themes we measured isn’t that we hit AA everywhere — it’s that we know where we don’t.

Step 4: package it
npm install -g @vscode/vsce
vsce package
Our result: 2.07 KB, five files. The resulting .vsix installs locally straight away — via the command palette with Extensions: Install from VSIX, or on the command line:
code --install-extension getmind-nord-test-0.0.1.vsix
Publishing additionally requires an Azure DevOps account, a publisher name and a personal access token; then vsce publish is enough. For personal use none of that is necessary — local installation works perfectly well.
The red test: what does vsce actually check?
At this point we wanted to know precisely. A green packaging run feels like an approval — but of what exactly? We took our working theme and damaged it systematically, one defect at a time.
Five defects in the colour values, each checked with vsce package:
| Test | Manipulation | Result |
|---|---|---|
| T1 | "editor.background": "dark-blue" (not hex) | ✅ packaged |
| T2 | "editor.background": "#GGGGGG" (invalid characters) | ✅ packaged |
| T3 | "editor.background": "#12345" (5 characters) | ✅ packaged |
| T4 | Typo in the key: editor.backgrund | ✅ packaged |
| T5 | Text #1B2029 on background #1B2028 (contrast 1.00) | ✅ packaged |
Not a single defect was reported. Not as an error, not as a warning. The package was produced in all five cases, at practically identical size.
🔑 This is the third finding, and the most practically important one: vsce checks the structure of the manifest, not the content of the theme. A typo in a colour key (T4) is especially treacherous because nothing anywhere flags it: VS Code silently ignores unknown keys, and the affected area simply keeps its default colour. And T5 — a theme in which the text is invisible — passes as entirely fine.
So that this isn’t just a claim about a tool that perhaps checks nothing at all, here’s the counter-check: what does vsce catch?
| Test | Manipulation | Result |
|---|---|---|
| G1 | Theme file doesn’t exist at all | ✅ packaged (!) |
| G2 | "uiTheme": "vs-purple" (invalid value) | ✅ packaged |
| G3 | engines.vscode missing | ❌ Manifest missing field: engines |
| G4 | "version": "not-a-version" | ❌ Invalid extension "version" |
| G5 | Theme label missing | ✅ packaged |
Only two of ten manipulations produced an error — and both concern mandatory manifest fields, not the theme.
Given the implications, we verified G1 separately instead of trusting the success message. We pointed the path at a non-existent file, packaged it, then looked inside the resulting archive:
extension/package.json 443 bytes
extension/themes/getmind-dark.json 897 bytes
The package.json in the finished package references ./themes/does-not-exist.json — a file not contained in the archive. vsce reports DONE Packaged, and the theme cannot possibly work.
🔑 The rule that follows: a green tool run is a statement about format, not about outcome. Anyone relying on vsce while building a theme has verified that their package is a valid ZIP with a valid manifest. About readability, colour correctness, or even the existence of the theme file, it says nothing. This is exactly where the 86% come from.

The practical conclusion is simple: the contrast check from step 3 is something you have to do yourself, because nobody else will. Ten lines of Python before publishing — that’s all it takes not to become part of the 86%.
Adjusting an existing theme without building one
For most cases the fastest route isn’t a theme of your own but a correction to the one you have. VS Code lets you override individual colours in settings.json, without touching the theme.
So if you like Tokyo Night but can’t live with a comment contrast of 2.50:
{
"workbench.colorCustomizations": {
"[Tokyo Night]": {
"editorLineNumber.foreground": "#8A94AB"
}
},
"editor.tokenColorCustomizations": {
"[Tokyo Night]": {
"comments": "#9AA5C0"
}
}
}
Two details that commonly cause trouble:
- The name in square brackets binds the override to that specific theme. Without it the change applies to all of them — and looks wrong the moment you switch.
- Interface and source code are separate, as described above:
workbench.colorCustomizationsfor the interface,editor.tokenColorCustomizationsfor the code.
For finer control there are textMateRules, which recolour individual scopes:
{
"editor.tokenColorCustomizations": {
"[Tokyo Night]": {
"textMateRules": [
{
"scope": ["comment", "punctuation.definition.comment"],
"settings": { "foreground": "#9AA5C0", "fontStyle": "italic" }
}
]
}
}
}
Which scope applies at the cursor is revealed by the command Developer: Inspect Editor Tokens and Scopes in the command palette. It also shows which theme rule is currently winning — considerably faster than guessing.
The value #9AA5C0 in the example lifts the comment contrast from 2.50 to above 4.5 without destroying the theme’s character. That’s the most pragmatic solution available: keep a theme you like and fix the one colour that bothers you.
What we use ourselves
We write a lot about measurements here, so the honest part: day to day we run a dark theme from the upper half of that table, not the one with the best contrast score. Colour choice is partly habit, and a theme with perfect numbers that you find unpleasant is a theme you won’t use.
What we did change is the comment colour — via exactly the textMateRules route above. It’s a three-line intervention that sticks, and it did more than any theme switch before it.
The recommendation that follows isn’t “use theme X” but: measure your current theme once. Ten lines of Python, two minutes of work. If the comment value comes in below 4.5 — which it will with 86% probability — fix it in settings.json and keep everything else.
Frequently asked questions
How many Visual Studio Code themes are there?
The Marketplace lists 19,679 hits in the “Themes” category, which after removing pagination duplicates corresponds to 18,420 unique extensions (measured 2 Sep 2026). That figure is misleading as an argument about selection, though: two thirds have fewer than 1,000 installs, and 73.4% of all installs go to the top 50.
Which VS Code theme has the best contrast?
In our measurement series GitHub Dark High Contrast performs best: 17.57 on editor text and 11.12 on comments — both comfortably above the strictest WCAG level, AAA. Among the popular mainstream themes, GitHub Dark Default (6.15) and Winter is Coming (Dark Blue) (6.44) lead on comment contrast.
Are themes with “High Contrast” in the name accessible?
Not reliably. Of 21 themes carrying “High Contrast” or “HC” in the name, 18 fail the WCAG AA requirement for comments. The most extreme example is Material Theme Lighter High Contrast with a base contrast of 2.59 — the lowest value in our entire series. The name is not a certification.
How do I create my own VS Code theme?
Two files suffice: a package.json with a contributes.themes entry, and a JSON file containing the colors block (interface) and tokenColors block (source code). Then run vsce package. Our complete example theme is 2,124 bytes and needs no build process, framework or JavaScript.
Does vsce validate my colour values?
No. We introduced five different colour defects — invalid colour names, impossible hex values, a typo in a key name, and a theme with contrast 1.00 — and all five were packaged without error or warning. vsce checks the structure of the manifest, not the content of the theme. It even waves through a reference to a theme file that doesn’t exist.
What’s the difference between colors and tokenColors?
colors paints the interface of VS Code — editor background, sidebar, status bar — using fixed keys such as editor.background. tokenColors paints the source code itself using TextMate scopes like comment or entity.name.function. If a colour seems missing, you’re usually looking in the wrong one of the two blocks.
How many colour keys does VS Code know?
In the source of microsoft/vscode (as of 1.137.0) there are 964 calls to registerColor(), producing 843 unique colour IDs. You don’t have to set them all: the median across the themes we measured is 237 keys set, with a minimum of 22. Anything unset inherits the default of the chosen uiTheme.
Can I change just a single colour of a theme?
Yes, via workbench.colorCustomizations (interface) and editor.tokenColorCustomizations (source code) in settings.json. With the theme name in square brackets the override applies to that theme only. This is the most practical way to fix a weak comment contrast without switching themes.
Why are comments so faint in almost every theme?
It’s a deliberate design decision: comments are meant not to compete visually with the code. In our measurements the median is 2.95 — well below the AA threshold of 4.5, in 86% of themes. But the underlying assumption (“comments are secondary”) stops holding as soon as someone reads unfamiliar code or has impaired vision.
Are light themes more readable than dark ones?
According to our data, no. Median comment contrast is 3.05 for dark themes and 2.83 for light ones. The share below WCAG AA is only slightly lower for light themes (76% versus 89%). The author’s colour choices decide this, not the overall brightness.
How do I find out which scope is under my cursor?
Through the command palette with Developer: Inspect Editor Tokens and Scopes. The command shows the TextMate scope at the cursor position plus which theme rule currently applies — the quickest way to target a single colour for change.
Conclusion
The VS Code Marketplace’s Themes category is both bigger and emptier than it looks: 18,420 entries of which roughly 500 cover essentially all actual use, two thirds untouched for years, and a ranking built on self-declarations — with a contentless joke package at number 10.
The real finding sits deeper, though. In 86% of the themes we measured, the comment colour is not sufficiently readable under WCAG, and the themes named “High Contrast” are mostly among them. That isn’t an oversight by individual authors but a structural gap: nothing in the toolchain checks it. In our red test vsce reported not one of five colour problems — not even a theme with contrast 1.00, nor a missing theme file.
Three practical consequences follow:
- Measure your current theme. Ten lines of Python, two minutes. The probability that the comment value fails is 86%.
- Repair rather than switch. Three lines in
settings.jsonlift a single colour over the threshold without giving up the look you like. - If you build one yourself: construction takes ten minutes and yields 2 KB. The contrast check is the part that separates it from the 86% — and you have to do it yourself, because nobody else will.
A theme isn’t a decorative object. It’s the surface you look at all day. Measuring it once is worth the effort.
Further reading:
- Firefox Themes: finding, installing and building your own — the same investigation for the browser, with a strikingly similar result regarding the official validation tool
- Learning TypeScript: the honest introduction — for anyone who wants to change more than the colours in their editor
- Open source web browsers compared — why “open source” is a weak selection criterion
- What is an .md file? — Markdown basics, including our free generator
