Error 0x80010135: Path too long pops up when Windows tries to extract, copy, or move a file and the full path exceeds what the system can handle. Here’s the thing — it’s almost never about the ZIP file being corrupted. The real issue is the total length of everything: your drive letter, all the parent folders, subfolders, and the final file name combined. Windows has a classic MAX_PATH limit of 260 characters, and even though newer versions can technically go longer in some situations, that support doesn’t work everywhere across every app or workflow.
Want the quickest fix? Move your ZIP to somewhere short like C:\Temp, give it a shorter name, and extract it right there. That alone fixes the problem most of the time because you’re immediately cutting down the path length Windows has to deal with.
Quick Fix: Create C:\Temp, move the ZIP there, rename it to a short name like update.zip, then try extracting again. If Windows Explorer still throws 0x80010135, use 7-Zip to extract the archive instead.
What causes the 0x80010135 path too long error?
You’ll typically run into this during:
- extracting a ZIP archive with the built-in Windows extractor
- copying deeply nested folders from one drive to another
- installing software from an archive that contains long internal folder structures
- working with developer files such as packages, repositories, logs, or generated build output
What catches people off guard is that the limit isn’t just about the file name itself. A simple file like readme.txt can still fail if it’s buried inside something like C:\Users\YourName\Downloads\Very-Long-Folder-Name\Another-Long-Folder\.... Microsoft’s maximum path limitation guide explains that many Win32 file APIs still use that 260-character MAX_PATH boundary, which is why Windows file operations can break even on newer systems in certain scenarios.
Best ways to fix error 0x80010135
Start with the simplest solution first. Most people don’t need to mess with the registry or group policies right away — they just need to shorten where they’re extracting to.
1. Move the ZIP file to a shorter path
This is what you should try first because it works surprisingly often and takes under a minute.
- Create a short destination folder: for example
C:\TemporC:\Zip. - Move the ZIP file there: do not keep it in
Downloadsif your Windows username or nested folders are already long. - Extract directly into that short folder: avoid creating extra subfolders before extraction.
Microsoft community threads for this error keep pointing back to extracting from a root-level spot because it immediately trims a big chunk of the full path. Atlassian and Broadcom support docs for the same Windows extraction issue recommend this exact approach for installer archives that fail with 0x80010135.
2. Rename the ZIP file to something shorter
If your archive has a long descriptive name, shorten it before you extract. Something like Project-Final-Backup-Version-2026-April-Archive.zip should just become backup.zip.
Sounds small, but the archive name counts as part of the path during extraction. Microsoft Answers threads specifically call out shortening the archive name as a practical workaround for 0x80010135.
3. Extract to the root of the drive
If moving to C:\Temp still doesn’t work, go even shorter. Extract straight to C:\ or a single-level folder like C:\X.
Why this matters: every folder adds characters. The difference between extracting to C:\Users\Vipin\Downloads\New Folder\Archive Output versus C:\X can easily be 40+ characters before Windows even touches the archive contents.
4. Use 7-Zip instead of Windows Explorer
The built-in Windows compressed folder tool is convenient, but it’s also where this error shows up most often. If Explorer keeps failing, grab 7-Zip for Windows and extract from its file manager instead of right-clicking in Explorer. Broadcom’s support docs explicitly recommend using another extraction tool like 7-Zip as a workaround for this exact error.
- Install 7-Zip: download the correct build from the 7-Zip download page.
- Right-click the ZIP file: choose
7-Zip>Extract to.... - Select a short output path: such as
C:\Temp. - Avoid drag-and-drop into Explorer: use 7-Zip’s direct extract command instead.
That last point is important. 7-Zip’s own FAQ mentions that drag-and-drop extraction into Explorer involves temporary files and Windows Explorer handling the destination, which can bring back Windows shell limitations. Direct extraction sidesteps that.
5. Enable long path support in Windows
If you regularly deal with deep folder structures, developer packages, Git repositories, or large exported archives, enabling long path support makes sense. Microsoft documents that starting with Windows 10 version 1607 and later, many common Win32 path limits can be relaxed — but only when the system setting is turned on and the application itself supports long paths.
That second part matters: enabling long paths can help, but it doesn’t guarantee every old app, installer, or Explorer workflow will suddenly work perfectly. Some tools still act like the classic limit exists.
Method A: Enable long paths with Group Policy
This option is typically available on Windows Pro, Enterprise, and some managed editions.
- Press
Win + R, typegpedit.msc, and press Enter. - Go to:
Computer Configuration > Administrative Templates > System > Filesystem - Open:
Enable Win32 long paths - Set it to:
Enabled - Click:
ApplyandOK - Restart your PC
Method B: Enable long paths with Registry Editor
This method works on Windows Home too, but be careful when editing the registry.
- Press
Win + R, typeregedit, and press Enter. - Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem - Find
LongPathsEnabled - Set its value to:
1 - Restart Windows
If the value doesn’t exist, create a new DWORD (32-bit) Value named LongPathsEnabled and set it to 1. Microsoft’s documentation uses this same registry value for enabling extended path behavior.
Method C: Enable long paths with PowerShell
If you’d rather use a one-line command, run PowerShell as administrator and use:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -ForceThis sets the same registry value without manually opening Registry Editor. The command is commonly used in Windows admin workflows and matches the documented registry setting for long path support.
Which fix should you try first?
| Situation | Best first fix | Why it helps |
|---|---|---|
| You only see the error while extracting one ZIP file | Move it to C:\Temp and rename it |
Fastest way to reduce total path length |
| Windows Explorer keeps failing on archives | Use 7-Zip direct extraction | Avoids the built-in Explorer extractor |
| You work with long nested folders often | Enable long path support system-wide | Better for recurring path-length problems |
| An installer archive fails during setup extraction | Extract to C:\ or C:\X first |
Many software packages ship with deep internal folders |
What to do if the error still appears after enabling long paths
This confuses a lot of people. They enable LongPathsEnabled, restart, then see the same error and think the setting did nothing. What’s actually happening is that both the system setting and app support need to be in place. If the extractor, installer, or shell component you’re using isn’t fully long-path aware, the problem can persist.
If that happens, try this order:
- Try a shorter extraction path again
- Switch from Explorer to 7-Zip
- Manually shorten parent folder names
- Check whether the archive contains extremely deep internal folders
So long-path support is helpful at the system level, but it’s not a universal override for every Windows file operation.
How to shorten a path without breaking your files
If the archive has an important folder structure and you don’t want to rename internal folders manually, the safest move is to shorten only what you control before extraction:
- rename the archive itself
- move it closer to the root of the drive
- extract into a one-letter or very short folder name
- move the extracted contents elsewhere after extraction finishes
For example, this is a bad extraction path:
C:\Users\YourName\Downloads\Client Files\April Deliverables\Website Backup\Extracted Archive\This is much better:
C:\X\Once everything extracts successfully, you can reorganize the files afterward.
Common mistakes that keep triggering 0x80010135
- Extracting from Downloads: the Downloads path under your user profile is often already longer than it looks.
- Using long descriptive folder names everywhere: one long folder is fine; ten in a row is how you hit the limit.
- Assuming ZIP corruption is the cause: in many cases the archive is valid and only the path length is the issue.
- Using Explorer after enabling long paths and expecting perfect behavior: some shell operations still behave inconsistently.
- Dragging files from 7-Zip into Explorer: direct extraction is usually safer for this problem than drag-and-drop.
When this error appears during software installation
If you downloaded an app, game, driver package, or enterprise installer and see 0x80010135 while opening the ZIP, don’t run the installer from a deep folder tree. Extract it first to a short path like C:\Install, then launch the setup file from there.
This happens a lot with vendor bundles that have many nested subfolders. Atlassian’s Jira upgrade guidance and Broadcom’s installer docs both show that deeply nested archive contents can trigger the same Windows extraction failure even when the package itself is perfectly fine.
Related troubleshooting that may also help
If your Windows system has broader file-operation or update issues beyond this one archive error, you might want to check my guide on fixing KB5063709 install failures, especially if file corruption or update servicing problems are happening alongside archive errors.
And if the machine has been unstable in other ways while you troubleshoot, my article on Chrome out of memory errors covers another common Windows-side issue that can make large downloads, browser extraction attempts, and heavy file workflows more frustrating than they should be.
For readers who regularly bounce between device troubleshooting topics, I also published a practical piece on ChromeOS repair loops, which follows the same “start with the least destructive fix first” approach used here.
Final Thoughts
The cleanest way to fix Error 0x80010135: Path too long is to reduce the full path before you do anything else: move the ZIP closer to the root of the drive, rename it, and extract it into a short folder. If Windows Explorer still fails, switch to 7-Zip. If this keeps happening on your system, enable Windows long path support so future file operations have a better shot at working. That combination solves the issue in most real-world cases without risky changes or unnecessary guesswork.
