How to Promote a VS Code Extension: A Solo Plan

Most advice for this is split in two. The official docs explain how to publish and say little about getting anyone to look. Forum threads ask the real question, how to promote an extension without being annoying, and answer it in fragments. Here is one plan in order, sized for one person with a few evenings a week.

Where do developers actually find extensions?

Mostly inside the editor. VS Code's own documentation describes the path: open the Extensions view, type the name of the extension, tool or language you want, and read a list where each result shows a short description, the publisher, the download count and a five star rating. Results can be sorted by installs, rating, name, published date or update date, and filtered by category and tag.

That tells you three things about your audience:

• They arrive with a need, not curiosity. Someone types "todo" or "docker" or "markdown table". They are not browsing for something to admire, so your name and description have to match the words they type.
• They judge from a small card. Before they open your page they see a name, a one-line description, an icon, an install count and stars. All five are decisions you can make on purpose.
• Sorting rewards history. Sorting by installs or rating favours extensions that already have them, which is why your first few weeks matter more than any single post.

Developers also arrive from outside: a link in a GitHub README, a mention in a blog post, a recommendation in a team chat. Those visits land on your marketplace page too. Either way, the listing is the page that closes the sale.

Which listing fields affect marketplace search?

The extension manifest reference is clear about the main ones. The displayName and description are used for text search in VS Code, so it helps to put relevant keywords there. The manifest also takes a keywords array that is included with the other tags on the marketplace page, and that list is capped at 30. Categories come from a fixed list and are what people filter on.

Here is every field that shows up on the page or in the search results, what to write, and where it appears. I have marked which ones the docs say are searched; the rest affect conversion rather than search.

Field	Where it shows	What to write	Searched?
displayName	Result card title, page header	The name plus the job, such as "Table Fixer: Markdown Tables" instead of a bare brand	Yes, per the manifest docs
description	Result card, page header	One sentence: what it does and for which language or task. No adjectives	Yes, per the manifest docs
keywords	Tags on the page	The words people type that are not already in the name. Up to 30, so use ten honest ones, not thirty padded ones	Included with tags
categories	Filter menus	One or two from the allowed list. Pick the one a user would filter by	Filterable
icon	Result card, page header	A PNG of at least 128 by 128 pixels. It cannot be an SVG	No, but it is the first thing seen
galleryBanner.color	Page header band	A hex color that matches your icon	No
README.md	The whole page body	See the next section	Shown on the page
CHANGELOG.md	Changelog tab	Dated, human-readable entries. Proof the project is alive	No
repository, bugs, homepage	Resources section	Real links that resolve. Missing ones read as abandoned	No
sponsor	Sponsor link	A page where people can support you, if you want one	No
LICENSE	License link	A real license file	No

Two cautions come straight from the publishing docs. Image URLs in the README and changelog must resolve to https URLs, and SVG images are blocked unless they come from trusted badge providers, so export your screenshots and GIFs as PNG, JPG or GIF. And if your repository field points at a public GitHub repo, vsce rewrites relative links in your README for you, using the main branch by default, so a relative image path will work on the marketplace page only if the file is committed there.

The practical test is simple. Search the marketplace for the three phrases a stranger would type to find your tool. If you do not appear for any of them, the fix is almost always in the name, description or keywords, not in more promotion.

What should the README show first?

The README is the page. Whatever sits above the first scroll is all that most visitors read, so build it like a landing page, not like repository documentation.

1. One sentence on what it does and who it is for. If a reader cannot repeat it back, rewrite it.
2. A short demo of it working. A GIF or screenshot of the thing happening inside the editor, showing the command, the result and nothing else. If you need a shot list, the guide to making an app demo GIF covers a twenty second version.
3. Install and first use in two lines. Name the command or keyboard shortcut that triggers it, and say what the user should see.
4. A settings table. Developers scan for configuration before they commit to installing.
5. Known limits. Say which languages, file sizes or editor versions it does not handle. This builds more trust than any adjective.
6. Where to report problems. A real issue tracker link.

Cut the rest of the architecture, contributing notes and build instructions down to links lower on the page or into the repository. Visitors read your README to decide whether to install, not to learn how you built it.

If you have worked on a Chrome extension too, the logic is the same one covered in the Chrome extension launch plan: a listing is a conversion page first and documentation second. The difference is that editor users find you from a search box inside the product they are already using, with a lot less patience for a vague description.

Should you publish to Open VSX as well?

Probably yes, and it takes about an hour once. Microsoft's marketplace is the default for VS Code, but Open VSX is the public registry at open-vsx.org, managed by the Eclipse Foundation, and it serves editors built on the same extension format that do not pull from Microsoft's marketplace. If your users work in one of those, an extension that exists only on the Microsoft marketplace is invisible to them.

The steps from the Open VSX publishing guide are short:

1. Create an Eclipse account, using the same GitHub account you log in to open-vsx.org with.
2. Log in to open-vsx.org, link the Eclipse account and sign the Publisher Agreement.
3. Generate an access token and store it somewhere safe. It is shown once.
4. Create a namespace matching the publisher field in your package.json, using npx ovsx create-namespace.
5. Publish with npx ovsx publish.

Two details save time. Creating a namespace does not mark you as its verified owner, so claim the namespace if you want the verified marker. And if the registry has extension scanning turned on, your upload is checked automatically for leaked secrets, known-bad files and names too similar to existing ones, so keep tokens out of your bundle.

Do this after the Microsoft listing is polished, not before. Both registries show the same README, so every fix you make to the listing page pays off twice. Add the Open VSX publish to your release script so it never drifts out of date.

One more credibility step is worth knowing about. The marketplace offers a verified publisher badge, but a publisher must have one or more extensions on the marketplace for at least six months, and the domain must be at least six months old. Put it on a calendar for later rather than chasing it at launch.

Where can you post about an extension without being removed?

Fewer places than you think, and each one has rules you should read before you post. The pattern that works is the same everywhere: show the extension doing something specific, say what you built it to solve, and ask for feedback instead of installs.

• A Show HN post, if the tool is interesting to a technical reader. It needs something people can try right away and a plain description of what it does. The Show HN checklist walks through the format and what gets a post flagged.
• The subreddit for your language or editor. Read the sidebar rules first, because many communities limit self-promotion to specific threads or require you to be an active participant. Post a short description with a GIF, not a link alone. Never post the same text to five subreddits in one afternoon.
• A write-up on a problem you solved. A post about how you handled something awkward, such as parsing a huge file without freezing the editor, reaches readers who never search the marketplace. Link the extension at the end, once.
• Issue threads where people ask for exactly this. If someone asks how to do the thing your extension does, answer helpfully and mention it as one option, with disclosure that you built it. Never drop it into unrelated threads.
• Your own GitHub README and other projects you maintain. A line in a repo that already has readers is the most targeted placement you have.

If your extension is open source, the same release habits in how to promote an open source project apply: tag a release, announce it in one or two places, answer every reply. And once it is live, list it where other developer tools gather. TryMy has a Dev Tools category that reviews submissions by hand, and listing there costs nothing.

Skip anything that looks like automation: paying for installs, asking friends to leave five star reviews in one afternoon, or posting in a dozen Discord servers with the same message. It is cheap to try and expensive to be known for.

How do you get the first ratings honestly?

Ratings come from people who got value and had a reason to say so. You can make that more likely without crossing any lines.

• Fix the first-run experience. Most one star reviews on small extensions describe confusion, not bugs. A clear command name and a visible result inside the first minute prevent many of them.
• Reply to every issue within a day or two when you can. A responsive maintainer turns an annoyed user into a satisfied one, and some of them will rate you afterwards.
• Ask once, in the right place. A single sentence at the bottom of your README, such as "If this saved you time, a rating on the marketplace helps others find it", is fair. A pop-up that reappears every session is not.
• Ask the people you are already helping. When someone thanks you in an issue, you can say you would appreciate a rating if they have a minute. They are the people most likely to mean it.
• Ship small updates often. The marketplace lets users sort by last update, and a visible changelog tells newcomers the project is alive.

Then measure, so you know what to change. The marketplace's publisher management page shows each extension's acquisition trend over time, total acquisition counts and ratings and reviews, so check it after each release. If installs rise after a post and drop after a week, the listing is converting but the extension is not sticking. If visits do not become installs, go back to the name, icon and first screen of the README.

A one week plan to start

If you want to begin now, here is the order that does the most with the least effort.

1. Day 1: Rewrite the name, description and keywords, then search for three phrases a stranger would use.
2. Day 2: Record one short GIF and rebuild the top of the README around it.
3. Day 3: Add a changelog, a license and working issue and repository links.
4. Day 4: Publish the same version to Open VSX.
5. Day 5: Write one post about a problem you solved and share it where that problem is discussed.
6. Weekend: Answer every comment and issue, and note which questions repeat. Those go into the README.

FAQ

How long does VS Code Marketplace publishing take?

The publishing docs do not give a fixed timing for a new version to appear, so do not plan a launch around a precise minute. Publish a day early, check that the page renders as you expect, and only then announce it. Note that verified publisher review is a separate process, which the docs say returns a result within five business days.

Do I need to publish to Open VSX?

No, you can publish only to the Microsoft marketplace and still reach VS Code users. But Open VSX serves editors that use the same extension format and do not use Microsoft's marketplace, so adding it widens who can install your extension. It needs an Eclipse account, a signed publisher agreement, a token and a namespace, and after that each release is one extra command.

Can I put a GIF in the extension README?

Yes. The docs require image URLs in the README to resolve to https, and they block SVG images except from trusted badge providers, so use a GIF, PNG or JPG and commit it to your public repository. Keep the file small enough that the page loads quickly, and put the GIF above the first scroll.

How do I see how many installs I have?

Open the marketplace publisher management page and select your extension. It shows the acquisition trend over time, total acquisition counts and your ratings and reviews. Check it after each release so you can see which actions changed the numbers.

Where to list it next

Once your extension is live on the marketplace, give it one more public home. Dev tools have their own TryMy category, and listings are reviewed by hand. Submit your extension free and a stranger can find, try and rate it from a page that is easy to share.