WinSetView: setting Explorer's default folder views across Windows 7 through 11

Explorer's per-folder memory problem and what WinSetView addresses

Windows File Explorer stores a view layout for each folder you visit, but that storage works per folder, not per type of folder. Open a folder, switch to Details view, adjust which columns appear, and set a sort order. Windows records that layout for that specific folder. Open a different folder and the view reverts to a default, or to whatever you last set on a folder Windows classifies in the same category. For anyone who wants a consistent Details view with specific column headings across the whole system, the built-in mechanism does not provide that without visiting every folder individually.

WinSetView sets a baseline that applies globally by folder type. A Documents folder and a Downloads folder both get Details view with the same column arrangement, because they belong to a folder type you configured. Individual folder customizations made in Explorer after you apply WinSetView take precedence over the type-wide defaults, but the starting point no longer drifts folder to folder.

Folder types as the unit of configuration, not individual paths

The most important concept before using WinSetView is that its interface labels name folder-type categories, not specific directories on disk. A label like "Pictures" targets every directory Windows has classified as that type across the whole system. C:\Users\Name\Pictures is one instance of that category, but so is any other folder Windows internally marks the same way, which can include directories in locations you might not expect.

Windows assigns folder types based on content, and that classification is not always predictable. A folder of downloaded PDFs may get classified differently from a folder of scanned images even if both sit in the same parent directory. The column layout and sort order you set in WinSetView apply to a type category, and any folder Windows assigns to a different type receives that type's settings instead.

WinSetView cannot target a specific folder path directly. For per-folder control outside of type assignments, Explorer's own right-click folder customization remains the only available path.

Three installation paths and what separates them

Three paths are documented for running WinSetView, and the choice comes down to portability and administrator privileges.

The recommended path is the zip file. Windows marks downloaded executables as potentially unsafe, so before launching WinSetView.exe you need to right-click it, open Properties, and tick Unblock. Skipping that step does not stop the app from running, but SmartScreen interrupts with a prompt that requires clicking More info and then Run anyway. A DownloadHelp.md file in the repository addresses cases where security software blocks the download entirely.

For scripted or repeat deployments, WinGet provides a single command:

winget install winsetview

The third option is WinSetView-Setup.exe, an installer that registers the app in the list of installed programs. This path requires administrator access. The zip and WinGet installs do not.

Portability is the zip's main advantage. Settings stay with the app files as long as the folder is writable, so a flash drive carrying the folder can configure multiple machines. A write-restricted location such as C:\Program Files (x86) causes Windows to redirect all settings writes to %AppData% instead, which keeps WinSetView functional but means the drive no longer carries a self-contained configuration.

What happens when you click OK in the Submit dialog

WinSetView applies no changes to Windows until you press Submit and confirm with OK in the dialog that follows. That design lets you explore the interface without consequence. Adjust view types, pick column headings, change the theme, and close the window with X to abandon everything. Only Submit commits anything to the registry.

The OK confirmation writes all queued changes to the registry and triggers an Explorer restart. That restart is why the README warns not to confirm while Explorer is in the middle of a copy, move, or delete, since the restart cuts those operations short.

The README also distinguishes which settings the X button saves. Font, font size, and theme are written to the INI file only when you click Submit. Position and dimensions of the WinSetView window are the one exception: they are written to disk on any X close, regardless of whether Submit was pressed. That behavior sits in the same paragraph as the general rule, "Nothing in Windows is changed, and no settings are saved, until the Submit button is pressed," making the exception easy to overlook because the two statements directly contradict each other.

Column headings shown in blue appear only in search results by default

The column headings selection page lets you specify which columns appear in Details view, in what order, their widths, and the group-by and sort settings. Hovering over interface elements shows descriptions; the manual contains the full reference.

One behavior requires reading before you start. Column headings shown in blue in the WinSetView interface are displayed only in search results by default, not in ordinary folder views. The README names Folder path (called File location in Windows 11) as a heading to keep enabled, because it serves that search-result context. If you assume blue-labeled headings work in all folder views and disable them, search results will lose those columns.

Icons view has a detail of its own. Selecting an icon size option causes a number to appear showing the current size. You can type a custom value: the README uses 72 as an example, describing that as a size half-way between medium and large. The input is not limited to preset sizes.

System Tray apps need manual exit before Submit; Store apps do not

The instructions ask for all open applications to be closed before pressing Submit, but what closed means differs by app type. System Tray apps require manual work: Discord, Steam, and qBittorrent keep a background process alive after their windows are dismissed. For those apps, the right-click menu on the System Tray icon, selecting Exit, is what actually stops them and ensures their file dialogs pick up the new view settings.

For Windows 11 Store apps, including Paint and Notepad, WinSetView issues an active termination during the apply step. A Store app that appears closed is still in memory, so a passive window close leaves its dialogs pointing at the old view settings, and WinSetView handles the kill to avoid that problem.

The practical consequence: a System Tray app left running before Submit will not show the updated column layout in its file dialogs until the app is relaunched. A Store app that is still open causes no problem, because WinSetView handles the termination. These two behaviors are described in separate caution notes rather than in one consolidated place.

What WinSetView cannot change and the fake winsetview.com site

WinSetView is limited to Explorer folder views. File associations, context menu entries, icon appearances beyond view size, and other Explorer settings are outside its scope. Changing what happens when you double-click a file type requires a separate tool.

Windows version support is declared as 7, 8, 10, and 11. A System-Requirements.md file in the repository provides details. The README gives only the version range; specific build requirements are there, not in the README itself.

WinSetView does not prevent Windows from reclassifying a folder. If a folder accumulates enough image files, Windows may change its type to Pictures, and the folder will then inherit the view settings you configured for that type. A manually set Explorer view for that folder is overwritten when the reclassification happens. WinSetView has no documented control over when Windows changes a folder's type.

The project is MIT-licensed, with the last release and push on 2026-09-21. The README includes a prominent warning that winsetview.com is a fake site operated by a third party; the only legitimate address is https://lesferch.github.io/WinSetView.

Editorial conclusion

WinSetView serves best when you manage multiple Windows machines or find yourself resetting Explorer column headings repeatedly after they revert to defaults. It is the wrong tool when you need per-folder control rather than type-wide defaults, or when your Windows version is outside the documented 7 through 11 range. Before the first Submit, close every System Tray app manually, check System-Requirements.md for your specific Windows build, and use only the official site at https://lesferch.github.io/WinSetView rather than winsetview.com.

Frequently asked questions

Official sources

1. Issues
2. LesFerch/WinSetView on GitHub
3. License: MIT
4. README
5. Releases