Why a zip says the path is too long

The zip is fine. Windows File Explorer rebuilds the whole folder tree that is stored inside an archive, and it refuses any finished path longer than 260 characters: a limit from the Windows API, not from the archive, not from your disk, and not from anything you did. The same file opens without complaint on a Mac, on Linux, on a phone, and in a browser. PACK opens it in the tab, tells you which name inside it is the long one and how much room that leaves, and saves files out under their own names with no folders at all, which is the one approach where the limit cannot apply. Nothing is uploaded.

What the error actually means

Extract All fails with the file name(s) would be too long for the destination folder, or its numeric form, 0x80010135. Before reading a single byte of your files, Windows works out where each one would end up:

the folder you are extracting into + \ + the path stored inside the archive

If that total passes the limit for any entry, the whole extraction stops. It is a length check, not a damage check. Nothing has been read, nothing has been decompressed, and nothing has failed a checksum.

Why 260

MAX_PATH is a constant in the Windows API, carried forward from a time when a path lived in a fixed-size buffer and never revisited, because too much software would break. It counts everything: the drive letter, the colon, every backslash, and a terminating null character that you never see. So 259 characters are usable.

NTFS, the filesystem underneath, allows 255 characters per name and around 32,767 for a whole path. The file you are trying to extract can exist perfectly well. It is the older way of asking for it that will not.

This is also why the archive opens everywhere else. Linux allows 4,096 bytes, macOS 1,024, and neither Android nor iOS gets anywhere near either. A colleague on a Mac unzipping your file without incident is not doing anything clever.

Find out how bad it actually is

Every zip carries a directory of its own contents at the end of the file, listing each entry under the exact path it was stored with. That list is readable without decompressing anything, so the number you need is already in the file you were sent.

Open the archive in PACK. If the longest name inside it is 120 characters or more, it says which one it is, how long it is, and the subtraction that follows: 259, less one for the separator, less that length, is the longest destination folder Explorer would accept. A real example from a shared drive:

Forty-five characters is enough for your downloads folder and almost nothing else. It is not enough for C:\Users\firstname.surname\OneDrive - Company Name\Documents, which is where a lot of people's files actually live, and that is the whole story of the error in one line.

Four ways past it

1. Rename the archive to something short. Extract All proposes a destination folder named after the zip, so a shorter name is a shorter destination. This buys you exactly the number of characters you removed: useful when you are a few over, useless when you are eighty over. It is the first suggestion everywhere and the weakest.
2. Extract to the root of the drive. C:\ is three characters, which is as short as a destination can be. This is the largest single gain available without installing anything, and it caps out there: if the names inside the archive exceed 255 characters on their own, nothing you do to the destination will help.
3. Use an archiver that asks for paths the long way. 7-Zip and its peers use the Unicode form of the Windows file APIs, which accepts roughly 32,767 characters, so they extract the tree intact. This genuinely works. It also means installing software, which on a managed laptop is a request to somebody else rather than a decision.
4. Do not recreate the folders. Open the archive and take the files out flat. Each one is saved under the last part of its name, so a 213-character path becomes one ordinary filename and there is no tree to be too long. PACK does this in the browser, on any machine, including the work laptop you cannot install anything on and the iPad where a zip attachment is otherwise a dead end.

The registry setting, and why it often does not help

Every article on this subject ends with the same instruction: enable Win32 long paths in Group Policy, or set LongPathsEnabled under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem. It is real, it has been available since Windows 10 version 1607, and it is not the switch people think it is.

The setting lifts the limit only for programs that declare themselves long-path aware in their own application manifest. A program that does not declare it keeps the old behaviour no matter how the policy is set, because the compatibility promise is the entire reason the limit still exists. That is why the same advice works for one person and does nothing for the next, and why it is worth understanding before editing a registry key on a machine your employer owns.

If you have the rights and want to try it, try it. Just do not conclude from it failing that something is wrong with your computer.

The folder you now cannot delete

A failed extraction can leave part of a tree behind, and that folder's path is too long for the same reason, so File Explorer will not delete it either. Right-click, Delete, and the same refusal.

Robocopy handles long paths, and mirroring an empty folder over the stuck one empties it:

mkdir C:\empty
robocopy C:\empty C:\stuck /MIR
rmdir C:\empty
rmdir C:\stuck

Look at what is inside the target first. /MIR makes the destination match the source exactly, and the source is empty, so everything in it goes.

What to do if you are the one sending the zip

The tree inside an archive is almost always an accident of how the files sat on the sender's machine, not something the files need. Three habits remove the problem at the source:

• Add the files, not the folder. Dropping a folder into a zip tool stores every level of it. Dropping the files themselves stores names only.
• Do not nest the project name three times. Project Review 2026\Project Review 2026 Final\Project Review 2026 Final v3\ is 90 characters of the same six words, and it is remarkably common.
• Check before you send. PACK lists what an archive declares, so you can see what the recipient will see. If it warns you, the recipient on Windows was going to hit the error.

One error that looks the same and is not

If File Explorer opens the archive, shows you the file names, and then fails only when you try to extract (with a wrong-password complaint, or a silently empty result), the problem is encryption rather than length. Windows reads only the 1989 zip encryption scheme, and most archivers now write the 2003 AES one. That is a different problem with a different answer.

Alongside: X-RAY tells you what a file really is when the extension is not to be trusted, and password-protecting a zip covers which scheme to choose so the person at the other end can actually open it.