Where Do VST3 Files Go on Windows? The Correct VST3 Folder

AvatarByEric Dawson Computers & Software

VST3 files go in C:\Program Files\Common Files\VST3 on Windows. That single folder is written into the VST3 specification by Steinberg, so every compliant DAW scans it automatically and no per-program path list is needed. A 32-bit plugin on 64-bit Windows lands in C:\Program Files (x86)\Common Files\VST3 instead. There is also a per-user location, %LOCALAPPDATA%\Programs\Common\VST3, which hosts read first but which most mainstream programs still treat as a developer path. Almost every installer picks the right folder on its own, so the usual fix for a plugin that will not appear is a rescan rather than a file move.

Where VST3 Files Go on Windows by Default

By default, Windows sends VST3 files to C:\Program Files\Common Files\VST3 for 64-bit plugins, with separate folders for 32-bit builds and per-user installs. Steinberg fixed these locations in the VST3 format specification, so installers and hosts follow them automatically with no per-program configuration. Three Windows folders matter in practice, and which one applies depends on whether the plugin is 64-bit, 32-bit, or installed for a single user account.

The 64-Bit System Folder

Nearly every VST3 plugin sold today is 64-bit, and it belongs in C:\Program Files\Common Files\VST3. Open File Explorer, paste that path into the address bar, and press Enter to see what is already there. A plugin usually shows up as a folder whose name ends in .vst3 rather than as one loose file, because the format keeps the binary next to its interface assets. Once a plugin is sitting here, a VST3 capable host picks it up on the next scan with no further setup.

The 32-Bit Folder on 64-Bit Windows

Older 32-bit plugins cannot live in the same folder as 64-bit ones. On 64-bit Windows they go to C:\Program Files (x86)\Common Files\VST3, the branch of Program Files that Windows reserves for 32-bit software. Most current DAWs run 64-bit only and ignore that folder entirely, so a plugin that lands there often looks like it vanished during install. Check the download page before assuming the installer misfired, since plenty of free and legacy plugins still ship a 32-bit build by default.

The Per-User Folder in AppData

A third location exists for installs that apply only to the signed-in account: %LOCALAPPDATA%\Programs\Common\VST3, which expands to C:\Users\[UserName]\AppData\Local\Programs\Common\VST3. Steinberg’s VST 3 Developer Portal lists it as the first place a host looks. Support for it is thinner than that ranking suggests. A JUCE forum thread from January 2022 flagged that the local directory was not yet well supported by DAWs, and the path is still used mainly during plugin development rather than for everyday installs. Treat it as a place to inspect when a plugin behaves oddly, not as somewhere to put files by hand.

How VST3 Hosts Scan for Plugins

VST3 hosts scan four locations recursively, in a fixed priority order, rather than checking one folder and stopping. The VST 3 Developer Portal documents that order, and it explains most cases where the wrong copy of a plugin loads.

Path Applies to Scan priority Typical use
%LOCALAPPDATA%\Programs\Common\VST3 Current user only 1, user level Development builds, per-user installs
C:\Program Files\Common Files\VST3 64-bit plugins, all users 2, global Standard system-wide installation
C:\Program Files (x86)\Common Files\VST3 32-bit plugins on 64-bit Windows 2, global Legacy 32-bit plugin support
Application folder, then VST3 The host program itself 3, application level Plugins bundled with a DAW

Priority is only half the rule. When the same plugin exists in more than one of these folders, the host keeps the first copy it matches by Processor UID and ignores the rest. That is why a stale build tucked into the user level folder can quietly override the current one in Program Files, and why the version number shown in a DAW sometimes disagrees with the version an installer just wrote.

Application level folders belong to the host and hold whatever shipped with it. Leave those alone unless a vendor support page tells you otherwise, because removing a bundled plugin can break the projects that used it.

I would trust the shared Program Files folder over the per-user AppData folder for a normal install. The user folder has the higher scan priority, but that makes it more likely to hide a newer system-wide copy when both contain the same plugin. For most readers, the simplest rule is to keep one current VST3 copy in the standard global folder and remove or update any older duplicate in the user folder. That reduces the chance of loading the wrong version without needing to manage paths in every DAW.

Why You Cannot Choose Your Own VST3 Folder

What the Specification Requires

VST3 folders are not user-selectable because Steinberg fixed the path directly into the VST3 format specification. The older VST2 format worked differently: every host kept its own list of plugin folders, which meant a new plugin often had to be pointed at from three or four programs separately. Compliant hosts scan C:\Program Files\Common Files\VST3 and only that global path, so one shared folder now does the coordinating that per-DAW path lists used to do. One consequence catches people out: most DAWs no longer show a VST3 path field at all, and a plugin installed somewhere unusual simply never appears.

Where VST2 Plugins Go Instead

The older format has not disappeared, and it uses different folders. A common one is C:\Program Files (x86)\Common Files\VST2 for 32-bit builds, though VST2 destinations were never standardized the way VST3 destinations are. Keep the two formats in separate folders. Modern VST3 hosts do not read the old VST2 structures, and mixing them makes it harder to tell which copy of a plugin a project actually loaded.

What VST3 Installers Do by Default

Almost all VST3 installers target C:\Program Files\Common Files\VST3 without asking. Some still present a folder picker, and since the VST3 destination is not theirs to choose, that picker normally applies to the other components in the same package: a VST2 build, a standalone application, a content or samples folder. Read the screen instead of clicking through, because a path field sitting directly above a fixed VST3 line is an easy thing to misread.

After the install finishes, restarting the DAW and running a rescan is the whole setup. No path needs adding, no preferences need editing, and the plugin turns up in the browser under whatever vendor name the developer registered. Compare that with VST2, where each host kept a separate folder list and every new plugin meant repeating the same configuration in each program you owned.

How to Move the VST3 Folder to Another Drive

Moving the VST3 folder to another drive means creating a Windows directory junction: the folder still exists at C:\Program Files\Common Files\VST3 as far as every host is concerned, while the actual files sit wherever you put them. The path itself is fixed, so a junction is the only practical workaround for a small system drive that cannot hold a large plugin collection. JDSherbert’s VST3 folder guide on GitHub and a long Renoise forum thread on the same problem both arrive at this approach.

Creating the Junction Step by Step

Here is the sequence for moving an existing collection to D:\VST3 on a machine where the default folder already holds plugins.

  1. Move the contents. Create D:\VST3, then move everything inside C:\Program Files\Common Files\VST3 into it.
  2. Delete the old folder. A junction cannot be created over an existing directory, so remove the now empty C:\Program Files\Common Files\VST3.
  3. Open Command Prompt as administrator. Press the Windows key, type cmd, and choose Run as administrator.
  4. Create the junction. Run mklink /J “C:\Program Files\Common Files\VST3” “D:\VST3” and wait for the confirmation line.
  5. Rescan in the host. Restart the DAW and run a full plugin rescan rather than an incremental one.

Every installer that targets the default path from then on writes straight through the junction to D:\VST3 without knowing anything changed. Windows presents the junction as an ordinary directory, so File Explorer, installers and hosts all follow it. One 40GB plugin library moved this way frees the same 40GB on the system drive, which on a 256GB laptop drive is the difference between working and not.

When a Junction Will Not Work

iLok protected plugins are the documented exception. Their copy protection cannot traverse a symbolic link, so those titles have to stay in the genuine C:\Program Files\Common Files\VST3 folder on the system drive. If a plugin misbehaves immediately after you create a junction, move that one plugin back to the real folder and test again before blaming the host. Nothing else in the chain has changed at that point, which makes it a clean test.

What to Do When a Plugin Does Not Show Up

Most reports of a missing plugin come down to four causes: the wrong folder, the wrong architecture, a cached scan, or an install that never completed. Work through them in that order, since the first two are quick to check and account for the majority of cases.

Checks to Run Inside Windows

  1. Look in the default folder. Paste C:\Program Files\Common Files\VST3 into the File Explorer address bar and confirm the plugin is actually there.
  2. Check the 32-bit folder. Open C:\Program Files (x86)\Common Files\VST3 and see whether a 32-bit build landed there instead.
  3. Check the user level folder. Paste %LOCALAPPDATA%\Programs\Common\VST3 into the address bar, because a stray copy here outranks everything else during the scan.
  4. Reinstall rather than drag. When a plugin is in the wrong place, run the installer again and let it choose the default path.

That last step matters more than it sounds. Dragging a .vst3 bundle to a different folder can break its interface assets and its links to preset files, which produces a plugin that loads but looks wrong or has forgotten its presets. Reinstalling takes a minute and leaves the file structure intact.

Confirming the Bit Depth Matches Your DAW

A 64-bit host loads 64-bit plugins only, and a 32-bit plugin sitting in the x86 Common Files folder is invisible to it. Check the vendor’s download page for the build you actually installed. Where both are offered, take the 64-bit version and let the 32-bit copy go, since current hosts are overwhelmingly 64-bit and the older build buys you nothing.

Checks to Run Inside the DAW

Hosts scan at startup, and many cache the result so later launches are faster. Force a full rescan instead of trusting the cache, then restart the program once more. No path configuration should be needed for VST3, so a host that still shows nothing after a clean rescan is telling you the problem sits on the Windows side rather than in its own settings.

If the Plugin Still Refuses to Load

Three things are worth ruling out at this stage. Some plugins need a separate license manager or activation step before a host will list them, so open the vendor’s own manager and confirm the license is present on the machine. Another frequent cause is an incomplete install from an interrupted download, which a full uninstall and reinstall clears. Failing both of those, look at whether an older copy of the same plugin is sitting in a higher priority folder and winning the Processor UID match.

Duplicate VST3 Plugins Across Scan Folders

Duplicate VST3 plugins happen when an installer writes to Program Files while an older manual copy still sits in the user level folder. The host then quietly loads whichever copy it matches first. Symptoms tend to be subtle: an outdated interface, a feature the changelog says arrived months ago, or presets that refuse to open.

Finding them is a matter of opening the same three folders and comparing. Look for the plugin’s .vst3 bundle in each one, note the modified dates, and delete the copies you did not install, keeping the one the current installer wrote. Priority order tells you which copy would have won: user level first, then the two global Program Files folders, then anything bundled with the host. Steinberg’s documentation describes that scan order but offers no cleanup tool, so this stays a manual job.

Plugin updates deserve the same care. The official documentation does not spell out what happens when a newer build lands in a lower priority folder than an old one, and the plain reading of the Processor UID rule is that the higher priority copy wins regardless of version. Removing the stale copy outright avoids the question entirely.

Frequently Asked Questions

Can I Change the VST3 Folder in My DAW Settings?

No. VST3 hosts follow the path set in the specification, and most DAWs no longer expose a VST3 path field at all. A Windows directory junction is the accepted way around it, since the official path stays in place while the files live on another drive.

Do VST3 Files Work on 32-Bit and 64-Bit Windows?

Both architectures have their own folder, and a plugin loads only in a host of the matching type. 64-bit plugins go to C:\Program Files\Common Files\VST3, while 32-bit plugins on a 64-bit system go to C:\Program Files (x86)\Common Files\VST3. Check which build you downloaded when a plugin installs without error and then fails to appear.

Is It Safe to Move VST3 Files by Hand?

Moving a .vst3 bundle after installation can break its interface assets and its preset links, so it is not the first thing to reach for. Running the installer again and letting it target the default folder is safer and usually quicker. Reserve manual moves for deleting duplicates you are certain about.

Where Does the VST3 Folder Live on a Per-User Install?

The per-user path is %LOCALAPPDATA%\Programs\Common\VST3, which written out in full is C:\Users\[UserName]\AppData\Local\Programs\Common\VST3. Steinberg’s developer documentation ranks it as the first folder a host checks. Everyday DAW support has lagged the specification here, so treat it as somewhere to inspect when a plugin behaves strangely rather than as an install target.

What Happens to VST2 Plugins After Installing VST3 Versions?

Nothing automatic. The two formats use separate folders and separate scan logic, so both copies stay installed and both can appear in a plugin browser. Delete the VST2 build when you do not want the duplicate, and keep it when an older project still references it.

For almost everyone the answer stays simple: let the installer write to C:\Program Files\Common Files\VST3, restart the host, and run a rescan. Reach for the 32-bit folder or the AppData path only when a plugin goes missing, and reach for a junction only when the system drive genuinely cannot hold the collection. Time spent hand sorting plugin folders is exactly the time the fixed VST3 path was designed to save.

What This Page Does Not Publish

  • I do not compare VST2 and VST3 prices or licence terms here.
  • I do not give a duplicate-plugin removal procedure; this page explains the folders hosts scan.
  • I do not troubleshoot update conflicts between copies in different scan paths.

References

Author Profile

Eric Dawson
Eric Dawson
I'm Eric Dawson, the writer behind The Money Watch. I live in the Columbus, Ohio area and I write about the ordinary questions that turn out to be complicated: computers, shopping, food, travel, parking, small businesses, fees, rules and products. Every article starts with the official page, the maker or the agency, then the sources that check it, and I say plainly where they disagree and what I would do. More about how I work is on the About page.