Free online tool
Check a VS Code extension before you install it
Drop a .vsix file — a VS Code extension package from outside the Marketplace — and inspect it before you install it: the tool unzips the package in your browser, reads the package.json manifest, and scans the shipped JavaScript for process spawning, network calls, eval, reads of credential paths, and hardcoded secrets. Nothing is uploaded, the extension is never installed, and nothing inside it runs.
Quick answer
Quick answer
Drop a .vsix file and this tool unzips it in your browser, reads the package.json manifest, and scans the shipped JavaScript for process spawning, network calls, eval, credential-path reads, and hardcoded secrets. You get a Safe, Suspicious, or Risky verdict — but it is a signals check, not antivirus, so a clean result never guarantees a package is safe.
Open the interactive VSIX Inspector
The interactive tool loads in the page. Enable JavaScript to enter data, process content, and download results.
Worked example — risky sample .vsix
The built-in risky sample, as scanned by the tool.
| File | sample-risky.vsix |
|---|---|
| Verdict | Risky — 6 points |
| Flags found | onStartupFinished, child_process |
| What to do | Do not install; check the publisher first |
What each flag means
| Flag | What it means | Risk |
|---|---|---|
| onStartupFinished | Extension activates the moment VS Code starts | High |
| child_process / exec / spawn | Code can start other programs on your machine | High |
| eval / Function | Code built from a string runs at runtime | High |
| Hardcoded secret | AWS key, GitHub token, or private key in the code | High |
| Network calls | Code talks to the network — fetch, http, WebSocket | Medium |
| Reads ~/.ssh / ~/.aws | Code touches paths where credentials live | Medium |
| Activation on * | Extension activates on every event | Medium |
| Encoded blobs | Decoded text or obfuscated content in the code | Low |
| Bundled binaries | Compiled files shipped in the package — listed, not analyzed | Info |
| No main entry point | Package ships no code — theme or language pack only | Info |
What to do next
| Verdict | What it means | What to do |
|---|---|---|
| Safe | No flags found | Still check the publisher, then install normally |
| Suspicious | Something unusual is present | Read the flagged code; try it in a throwaway profile first |
| Risky | Serious markers found | Do not install — delete it or quarantine and report it |
About this tool
About the VSIX Inspector
Drop a .vsix file — a VS Code extension package from outside the Marketplace — and inspect it before you install it: the tool unzips the package in your browser, reads the package.json manifest, and scans the shipped JavaScript for process spawning, network calls, eval, reads of credential paths, and hardcoded secrets. Nothing is uploaded, the extension is never installed, and nothing inside it runs.
Detailed guide
How to get useful results from VSIX Inspector
What a .vsix file really is
A .vsix file is a ZIP package. Inside it sits a package.json manifest — the extension's name, publisher, version, the VS Code version it needs, the events that activate it, and the commands, views, and settings it contributes — plus the JavaScript that actually runs when those events fire. The Marketplace checks packages before listing them; a .vsix handed to you by a colleague, a forum post, or a repository has had no such check.
That gap is the risk. In 2025 and 2026, waves of malicious VS Code extensions were found in the Marketplace itself — extensions that sat quiet for weeks, then turned on their users. A package from outside the Marketplace skips even the listing review, so the only check left is the one you run yourself, before installing.
How the inspector opens a package without installing it
The tool never installs the extension and never runs anything inside it. It reads the file's bytes with the File API, opens it as a ZIP archive in your browser, and lists every file it contains. The manifest is read from extension/package.json, and the shipped JavaScript files are decoded as text and scanned against a fixed table of capability and secret patterns.
Everything happens in this tab: the file is never uploaded to a server, so a sensitive or internal extension stays on your machine. The report is built from what the package actually contains — manifest fields, the exact patterns matched, and the file each one sits in — so you can verify every claim instead of trusting a single score.
What each flag means
The biggest flags are about code that can act: child_process and friends can start other programs on your machine, and eval or the Function constructor can run code built from a string at runtime — including code the extension fetched or decoded, which no static scan can see. A hardcoded-secret pattern — an AWS key, a GitHub token, a chat token, a private key — means a live credential may be sitting in a package anyone can download.
Some flags are less certain. Network calls are normal for extensions that check for updates or sync settings, but they are also the channel for sending data out. Reads of .ssh, .aws, or .gnupg paths are a serious marker unless the extension exists to manage credentials. Activation on startup, or on every event with *, means the code runs before you ever use it — normal for some tools, and exactly what a malicious extension wants.
How the verdict is worked out
Every flag carries points: high-severity flags are worth 3, medium ones 2, low ones 1, and informational notes 0. A package with no flags scores 0 and gets a Safe verdict. A score of 1 to 3 is Suspicious — something unusual is present, but it may have an innocent explanation. A score of 4 or more is Risky — the package has multiple serious markers, or one flag that alone is enough to be dangerous.
The score is deliberately simple and shown in the report, so you can see exactly why a package got its verdict. A bundled binary adds no points at all — it is listed for you to check with antivirus, not counted against the package. But startup activation alone scores 3 and reads Suspicious, because code that runs the moment VS Code starts deserves a second look. Startup activation plus a process spawn scores 6, and there is no innocent reading of that pair.
What to do next, by verdict
Safe means nothing was found — but it is not a guarantee, so still check the publisher before installing a package from outside the Marketplace, and prefer the Marketplace listing when one exists. Suspicious means something unusual is present: read the flagged code, check who published the package, and install it in a throwaway VS Code profile first if you still want it.
Risky means the package has serious markers — startup activation with a process spawn, a hardcoded secret, or several of those at once. Do not install it. Delete it, or quarantine it and report the source — the forum post, the repository, or the person who sent it — so others are warned. If it arrived by email, report the message as phishing rather than just deleting it.
What this check cannot see
This is a signals check, not antivirus. It reads the manifest and the visible source — it does not run code, and it cannot see what minified, bundled, or machine-generated JavaScript hides from a plain-text scan. The visible source can differ from compiled code, so a risky package can look clean and an honest one can look suspicious. Binary files are listed, not analyzed: a bundled executable is a blind spot.
An upload-based scanner such as VSCan is the honest second opinion — it sees the same package from the server side, at the cost of uploading it. And no static check replaces the simplest test of all: installing an unknown extension in a throwaway profile, watching what it does, and only then deciding whether it belongs on your real machine.
Who checks a .vsix this way
Developers handed an extension outside the Marketplace — a .vsix from a colleague, a forum, or a repository — are the main audience: the tool answers the question of whether to install it, without installing it. Security-conscious developers check packages the same way after the malicious-extension waves of 2025 and 2026, when extensions that had sat quiet for weeks turned on their users.
The same check fits anyone who reviews extensions for a team: read the manifest, see when the code activates, see what it can do, and decide from the report rather than from a stranger's assurance. The built-in samples show both ends of the scale — a clean greeter extension and a risky one that spawns a process at startup — so you can see what each verdict looks like before you trust it with a real file.
Quick guide
How to use this tool
- 01Drop a .vsix file onto the upload area, or browse to choose one — up to 25 MB.
- 02The tool unzips the package in your browser, reads the package.json manifest, and scans the shipped JavaScript.
- 03Read the verdict — Safe, Suspicious, or Risky — and the points behind it.
- 04Open each finding to see what it means and which file it sits in, and read the manifest summary and file inventory.
- 05Copy the report, then follow the next step for the verdict — install, test in a throwaway profile, or delete.
Capabilities
Features and supported formats
- Unzips a .vsix package in your browser and reads the package.json manifest — publisher, version, VS Code engine, activation events, and contributions.
- Scans the shipped JavaScript for process spawning, network calls, eval, reads of credential paths, and hardcoded secrets.
- Flags startup activation (onStartupFinished) and activate-on-everything (*) as the broadest ways an extension can run.
- Scores each flag and explains the verdict — Safe, Suspicious, or Risky — in plain English.
- Lists every file in the package, with sizes, and names bundled binaries instead of pretending to analyze them.
- Runs 100% in your browser; the file is never uploaded, installed, or executed.
Supported formats
Input: one .vsix file, up to 25 MB. Output: an on-screen report — verdict, score, manifest summary, findings with file paths, and a full file inventory — with a copyable text report. Nothing is downloaded unless you copy it.
Answers
Frequently asked questions
Does the VSIX Inspector upload my .vsix file?
No. The file is unzipped and inspected entirely in your browser tab. It is never sent to a server, stored anywhere, installed, or executed. You can use it on an internal or sensitive extension without it leaving your machine.
Is a Safe verdict a guarantee that the extension is safe?
No. This is a signals check, not antivirus: it reads the manifest and the visible source, and minified or bundled JavaScript can hide capabilities from a text scan. A clean result means this scan found nothing — it never guarantees a package is safe.
What is a .vsix file?
A .vsix file is a VS Code extension package — a ZIP archive containing a package.json manifest and the extension's code, themes, or language files. The Marketplace distributes extensions as .vsix files, and developers can also share them directly, outside the Marketplace.
Why is onStartupFinished flagged?
onStartupFinished means the extension activates the moment VS Code starts, before you run any of its commands. Many honest tools need that — but it is also what a malicious extension uses to run immediately, every time, with no click, which is why it scores 3 points on its own.
Is spawning a process always malicious?
No. Linters, formatters, and language servers routinely spawn their own binaries, and that is legitimate. A process spawn is a signal to investigate, not proof of malice — read the flagged code, check the publisher, and see whether the process makes sense for what the extension claims to do.
What should I do with a Risky package?
Do not install it. Delete it, or quarantine it and report the source — the forum post, repository, or person who sent it. If it arrived by email, report the message as phishing so the sender gets blocked.
Can the tool check an extension already installed in VS Code?
Not directly. Installed extensions live in your VS Code extensions folder; to check one, zip its folder, or find its .vsix from the publisher, and drop that file here. For installed extensions, the audit tool ExtGuard checks them inside VS Code itself.
What is the file size limit?
One .vsix file, up to 25 MB. Most extensions are far smaller than that; very large packages usually bundle binaries or language models, which this scan lists but does not analyze.
Does the tool run the extension's code?
Never. It only reads the manifest and scans the shipped JavaScript as text. Nothing inside the package executes in your browser or in VS Code, which is the whole point of checking before installing.
What are bundled binaries, and why are they not analyzed?
Some extensions ship compiled files — .node, .exe, .dll, .so — alongside their JavaScript. This scan lists them with their sizes but cannot tell what they do, because a text scan cannot read a binary. Check them with an antivirus scan before installing.
Does this replace VSCan or antivirus?
No. VSCan is an upload-based scanner that checks a .vsix from the server side, and antivirus checks binaries this tool cannot read. Use this inspector as a fast first check that never uploads your file, and VSCan or antivirus as the second opinion.
Can I use it on my phone?
Yes — the page works in a mobile browser, and the samples run there too. But a .vsix is a desktop VS Code package, so in practice you will usually inspect it on the computer where you plan to install it.