A VS Code extension has two separate names living in the same package.json file, and most extension authors never notice the second one. The name field is the lowercase technical identifier used in the marketplace URL and the install command. The displayName field is what shows up in search results and the extensions panel. Most developers fill in the identifier without thinking, then spend real effort on the displayName, not realizing both fields decide whether anyone finds the extension. This split is not unique to VS Code. The same two-name problem shows up in library naming, and in any developer tool that pairs a machine readable identifier with a name people search for.
Two names, one extension, and why the split trips people up
Open package.json for any extension and you will find two fields doing very different jobs.
"name": "my-extension""displayName": "My Extension"
The name field must be lowercase. It matches the pattern used in the extension's unique identifier alongside the publisher name, written as publisher.extension-name, and it appears in the marketplace URL and the CLI install command. The displayName field is a free text string with no formatting restrictions, and it is what appears prominently in search results and the extensions panel. Based on Microsoft's own documentation, the displayName and description are directly used for text search inside VS Code, so relevant keywords in both fields affect whether anyone finds the extension. Most extension authors treat the name field as a technicality, then focus all their creative energy on the displayName, without realizing the name field also determines the install command a user might type or share, which matters more than it looks like at first glance. Any developer tool that pairs a machine readable identifier with a human facing name runs into this same split, and the same two-name problem shows up in library naming.
A real example of what happens when the identifier gets lost
A developer named Fabio Spampinato built a VS Code extension called Todo+, with the full identifier fabiospampinato.vscode-todo-plus. He documented a specific, concrete problem in a public GitHub issue, not a hypothetical. Running the exact install command for his own extension's ID, ext install vscode-todo-plus, did not surface his extension anywhere in the top 10 search results, even though the string was an exact match for the identifier itself. He had already added a note to his own README instructing users to search by exact ID to work around the search ranking problem, and he noted that other extension authors had quietly done the same thing for their own extensions rather than fight the ranking directly. The lesson here is specific and not obvious. Even a name that is an exact technical match to the search query a user types can still lose to marketplace ranking factors like install count and relevance scoring, factors that have nothing to do with the name itself. A good name is necessary but not sufficient. The same discipline of checking your name against the platform's real search behavior before committing applies across every developer tool, not just VS Code extensions, and the same discipline applies to CLI tool naming just as directly, since a terminal command faces this same ranking problem in a slightly different form.
What actually makes a displayName findable
Lead with the function, not the brand
“Prettier” describes nothing about what the extension does on its own, but it succeeds because the brand itself became the search term over years of steady adoption. A new extension does not have that luxury yet. “Code Spell Checker” and “GitLens” both lead with a plain description of function, which is why a developer searching for what they need finds them without already knowing the name in advance. For a new extension with no existing recognition, a displayName that states the function plainly will outperform a clever brand name in marketplace search almost every single time, at least until the brand earns its own recognition.
Match the keywords a developer actually types
Marketplace search weighs both the displayName and the description field for text matching, and it does this in a fairly literal way. If your extension formats JSON files, the words “JSON” and “format” should appear naturally in one of those two fields, not just implied by the extension's name or icon. This is not keyword stuffing, since the marketplace search is a straightforward text match against real words, not a ranking algorithm sensitive to keyword density or repetition. Include the specific words a developer would actually type into the search box when they need what your extension does for them, in whichever field reads naturally, since the marketplace treats both the same way.
Keep the technical identifier boring on purpose
Since the name field has to be lowercase with no spaces, resist the urge to make it clever anyway. A technical identifier like “json-fmt-pro” reads worse in an install command than a plain one like “json-formatter” ever would. The name field is infrastructure, similar in spirit to a GitHub repo slug that other tools and scripts will reference. It should be predictable and descriptive, not distinctive or memorable on its own. Save the personality for the displayName, where formatting is unrestricted, following the same lowercase discipline that applies to repo slugs everywhere else in a developer's toolchain. A boring, predictable name field costs you nothing, since no one ever searches for it directly.
A pre-publish naming check for extensions
- 01Search the VS Code Marketplace directly for the exact function your extension performs, using the plain words a developer would naturally type into the search box, and see what already ranks for that query before you commit to anything.
- 02Confirm your name field is lowercase, hyphenated where needed, and contains no special characters, since the marketplace enforces this exact format strictly and will reject anything that breaks it.
- 03Write your displayName as a plain description of function first, then revise it for concision once the meaning is clear. Resist the urge to start with a brand name if you have no existing recognition to lean on.
- 04Check that your description field contains the same core keywords as your displayName, since both fields are weighted in marketplace text search and repeating the keywords reinforces the match.
- 05Run the exact install command your name field would generate and confirm it is short enough to type or share out loud without sounding awkward or embarrassing to say, since users do sometimes read these commands aloud to each other.
Name the identifier plainly, name the extension clearly
The technical identifier and the display name serve different audiences and different purposes, and treating them as a single decision is the most common mistake extension authors make before they ever publish. Getting this right early saves you from a painful rename later, once install counts and reviews are attached to the identifier. NameKit's Project Name Generator is a reasonable place to start for generating a pool of name candidates before deciding which one becomes the identifier and which one becomes the display text.
Frequently asked questions
What is the difference between name and displayName in a VS Code extension?
The name field is the lowercase technical identifier used in the extension's unique ID and marketplace URL. The displayName is the human readable text shown in search results and the extensions panel. Both fields affect discoverability, but they serve different technical purposes and follow different formatting rules entirely.
Does the extension name affect search ranking in the VS Code Marketplace?
Yes. Microsoft's own documentation confirms the displayName and description fields are used directly for text search inside VS Code. Relevant keywords in both fields help a developer searching for a specific function actually find your extension among the many similar options already listed, instead of scrolling past it entirely without noticing it exists.
Can I change my extension's name field after publishing?
The name field is part of your extension's permanent identifier alongside your publisher name. Changing it effectively creates a brand new extension listing, losing your existing install count and reviews in the process. The displayName, by contrast, can be changed freely at any time without this consequence.
Why did a well named extension not appear in marketplace search?
A documented case involved an extension where searching the exact install command for its own identifier did not surface it in the top 10 results. Marketplace ranking considers install count and other relevance factors beyond exact text matching, so a good name is necessary but not sufficient for discoverability on its own.
Should my extension name describe what it does?
For a new extension with no existing brand recognition, yes. A plainly descriptive displayName matches what a developer actually types when they search. Established extensions can rely on brand recognition alone once they have it, but a brand new extension benefits far more from leading with function until that recognition is actually earned.