How to Enable Long File Paths in Windows 10 and 11: Settings and App Compatibility

For Windows 11 users, the useful takeaway is not simply “change this registry value.” It is understanding when the setting can help, applying it safely, and checking the application that actually failed. Otherwise, a successful registry edit can leave you staring at exactly the same error message.

What the 260-character limit actually measures​

MAX_PATH is a longstanding limit associated with many Windows API file operations. It measures the path to a file, rather than just the name displayed underneath its icon. The drive designation, directory names, separating backslashes, filename, and extension all contribute. Technically, the traditional 260-character allowance also includes the invisible terminating null character used by the API.

Consider this illustrative location:

C:\Work\Client Projects\Annual Reports\Review Copies\Approved\report.docx

The relevant string is the entire address, not merely report.docx. Adding descriptive folder names repeatedly consumes the available space, even if the filename itself stays short. Windows naming documentation describes paths as a hierarchy of components, each of which can also have its own length constraint.

This distinction explains why reducing folder depth can help without changing the document. It also explains why blaming NTFS alone misses the point. Microsoft documents extended-length paths of approximately 32,767 characters through supporting Unicode APIs, with individual components commonly limited to 255 characters. That larger figure is a capability with conditions—not a promise that every Windows application can open a file at such a location.

MakeUseOf’s account is therefore consistent with a path-length problem, but it is not a complete diagnosis of the unnamed application. Moving a file and seeing it open is a useful clue; it does not, by itself, establish which part of the software rejected the original location.

What Microsoft changed—and what remains unchanged​

Microsoft introduced the relevant opt-in behavior with Windows 10, version 1607. It removed MAX_PATH restrictions from many common Win32 file and directory functions when the necessary conditions are met. The mechanism also applies to later Windows versions, including Windows 11. This is an existing Windows capability, not a newly released repair or a fresh cumulative-update fix.

There are two requirements:

1. Windows must have the machine-level LongPathsEnabled registry value set to 1.
2. The application must declare long-path awareness through its application manifest.

Both matter. The system setting enables the behavior; the application declaration opts the executable into it. Microsoft’s documentation specifically warns that changing the registry value does not affect all applications.

This is the central limitation of the “one tweak” framing. The tweak is genuine, but it cannot rewrite an older application’s internal path-handling code.

Nor should users expect the Windows shell and the file system to behave identically. Microsoft warns that an API can create a path that the shell interface cannot interpret correctly. Its separate support guidance on file-path limits also says File Explorer and Office desktop applications do not currently opt into the long-path setting. For those applications, enabling the policy alone should not be treated as a guaranteed solution.

The practical distinction: Windows supporting a longer address and your application successfully using that address are separate tests.

Before changing anything​

Use the following procedure for Windows 11 or Windows 10 version 1607 and later. You will need administrative authorization to change the machine-level configuration; Microsoft likewise specifies elevated privileges for its PowerShell alternative. On a work-managed device, ask IT to make or approve the change rather than trying to override organizational configuration.

My recommended preparation is straightforward:

• Save your work before restarting.
• Record the original policy or registry state.
• Choose one configuration method rather than changing both independently.
• Keep a backup of any important file used for testing.
• Avoid reorganizing shared project folders merely to experiment.

Before editing the registry, back up the relevant key. Microsoft’s documented process is to open Registry Editor, select the key, choose File > Export, give the backup a name, and save it. Its restoration procedure uses File > Import. For this task, select the FileSystem key shown below before exporting. Also note whether LongPathsEnabled already exists and its original value.

That record is useful even if you never need to reverse the change. Troubleshooting is considerably easier when “what did we change?” has an exact answer.

Method 1: Enable Win32 long paths through Group Policy​

MakeUseOf’s walkthrough uses the Local Group Policy Editor on Windows 11 Pro and identifies Enterprise and Education as additional editions offering that route. Microsoft independently documents the policy location and lists Pro, Enterprise, and Education among editions supported by its corresponding device-management policy.

To enable the setting:

1. Open Windows Search.
2. Type gpedit.msc and open the Local Group Policy Editor.
3. Navigate to:
   
   Code:

   Computer Configuration
     > Administrative Templates
       > System
         > Filesystem

4. Open Enable Win32 long paths.
5. Select Enabled.
6. Select Apply, then OK.
7. Restart the PC before testing the affected application.

Microsoft confirms the policy’s full location as Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths.

The restart recommendation is deliberate, but there is a technical nuance: Microsoft says a reboot might be required, not that every change invariably requires one. The registry setting is cached separately for each process after its first affected file-operation call, and that process does not reload the value during its lifetime. Restarting provides a cleaner test than assuming every relevant process has already picked up the change.

If your Windows edition does not provide the Local Group Policy Editor, use the registry method instead. There is no need to introduce an unofficial editor-installation workaround for this task.

Method 2: Enable long paths through Registry Editor​

MakeUseOf presents Registry Editor as the route for Windows 11 Home users. The underlying value is the same machine-level setting documented by Microsoft; it is not a separate, more powerful workaround.

Follow these steps carefully:

1. Open Windows Search, type regedit, and launch Registry Editor.
2. Approve the administrator prompt if authorized.
3. Navigate to:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
4. Export the key as described above before editing.
5. Locate the value named LongPathsEnabled.
6. If it is absent, create a DWORD (32-bit) Value with that exact name.
7. Open the value and set Value data to 1.
8. Select OK, close Registry Editor, and restart before testing.

Microsoft specifies the value’s type as REG_DWORD, its name as LongPathsEnabled, and its enabled data as 1. Use that documented type rather than substituting a different registry value type.

For administrators who prefer a command, Microsoft supplies this equivalent PowerShell operation, to be run with elevated privileges:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
  -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

This is an alternative way to set the same value—not an additional repair to run after the graphical method. The same application-compatibility and process-restart conditions still apply.

How to tell whether it worked​

There are two different outcomes to verify: the setting changed, and the original operation now succeeds.

First, reopen Registry Editor and inspect the exact value. Confirm that LongPathsEnabled is a DWORD with data 1. If it was already 1 before you started, setting it again does not satisfy any missing application-side requirement. Microsoft’s two-condition model still applies.

Then test the affected application after restarting. My recommended test sequence is:

1. Use a backed-up or disposable copy of the relevant file.
2. Try the operation that originally failed at the long location.
3. If the workflow includes saving, test saving—not just opening.
4. Close and reopen the test file.
5. Record the application version, location, and exact error if it still fails.

Success means the original workflow works in the intended location, not merely that Registry Editor accepted the number.

If the failure remains, avoid repeatedly toggling the setting. Microsoft’s documentation establishes several boundaries worth checking:

These checks follow from Microsoft’s application-manifest requirement, process-caching explanation, component limits, and shell warning.

When shortening the path is still the right fix​

A workaround is not necessarily a bad solution. If the application cannot use long paths, moving a working copy into a shorter directory structure may be more useful than changing system configuration that the application ignores.

For example, a project stored beneath several layers of administrative folders could be tested in a short, authorized workspace. Treat that as a controlled experiment, not an instruction to relocate production data or break a team’s established folder structure.

Cloud storage adds another boundary. Microsoft documents a 400-character decoded-path limit for OneDrive and SharePoint cloud storage, separate from desktop application limits. It also explains that synchronizing a file adds a local folder prefix, potentially making its Windows address longer than the cloud-relative address. If File Explorer cannot rename an affected cloud-stored item, Microsoft recommends shortening its name or location through OneDrive or SharePoint on the web.

The Windows setting therefore does not abolish service-specific limits. Test the complete workflow, including synchronization, rather than assuming that opening a local file proves everything downstream will work.

What developers and IT administrators should take away​

For developers, the manifest declaration is part of the application’s compatibility work, not an end-user registry trick. Microsoft lists affected functions including CreateFileW, CopyFileW, DeleteFileW, and MoveFileW. The documented change concerns specified APIs, not every possible route through a runtime, library, or application.

Microsoft also documents extended-length syntax such as:

\\?\D:\very long path
\\?\UNC\server\share

These forms have special rules: they do not accept forward slashes as separators or the usual . and .. relative components. Relative paths remain subject to MAX_PATH. This is developer-facing context, not a recommendation to paste prefixes into every application’s Open dialog.

For IT teams, Microsoft documents central management through Group Policy and Intune’s Policy Configuration Service Provider. My deployment recommendation is to pilot the setting against actual business workflows before broad rollout. Include opening, editing, saving, moving, and whatever backup or synchronization processes the organization relies upon. A successful test in one executable does not establish compatibility for the others.

A useful setting, with a clearly defined boundary​

MakeUseOf’s story highlights a genuine Windows frustration and a legitimate configuration option. The stronger advice is more precise than “remove the limit”: enable long-path support for applications designed to use it, then verify the workflow that matters.

If the application still fails, shorter paths remain a sensible response. The registry switch can open the door; it cannot make every application walk through it.