How do I find files with long paths in SharePoint Online?

Enumerate the library with Get-PnPListItem, take each item's FileRef, add the local sync prefix for the client you care about, and compare against that client's limit (260 for Windows Explorer, 259 for Office, 400 for the service). Export the results to CSV.

Is there a tool to scan SharePoint sites for long file paths?

TreeSize and similar tools scan a synced local copy, not the site, so they only see what already synced. A scan against the SharePoint API, like the PowerShell in this post or SyncHealth365, sees every item including the ones that never made it down.

What is the maximum path length for SharePoint Online?

400 characters for the decoded path from the document library root, with each file or folder name limited to 255 characters. Windows devices add their own 260-character limit on the local synced path.

Why does the SharePoint long-path PowerShell script fail?

Most published scripts load every item with a single unpaged call and hit the 5,000-item list view threshold, or run out of memory on large libraries. Use -PageSize with Get-PnPListItem and request only the FileRef field.

Find every file in SharePoint whose path is too long to sync (before the migration does)

The PnP script everyone links errors out on large libraries, and it only checks the 400-character server limit anyway. Here is one that survives big libraries and checks the limit users actually hit — and why the per-client version needs more than a script.

Before a migration, a tenant rename, or the day someone finally turns on sync for the finance library, you want the list of paths that will not fit. The script on every forum gives you the 400-character server limit, which almost nothing exceeds, and crashes on libraries over a few thousand items. Here is the one that answers the real question.

The real question

Not "is the SharePoint path over 400?" but "when this syncs to a Windows laptop, is the local path over 260 (or 259 for Office)?" The local path is:

C:\Users\<username>\OneDrive - <Tenant display name>\<Site name> - <Library name>\<SharePoint relative path>

That prefix alone is often 70–100 characters. So the usable budget for the SharePoint part is roughly 160–190 characters, not 400.

A script that survives large libraries

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Finance -Interactive

$lib     = 'Documents'
$prefix  = 'C:\Users\username12\OneDrive - Contoso Holdings BV\Finance - Documents\'   # longest realistic local prefix in your tenant
$libRoot = (Get-PnPList -Identity $lib).RootFolder.ServerRelativeUrl                    # e.g. /sites/Finance/Shared Documents

Get-PnPListItem -List $lib -PageSize 2000 -Fields FileRef |
  Where-Object FileSystemObjectType -eq 'File' |
  ForEach-Object { $prefix + ($_['FileRef'].Substring($libRoot.Length + 1) -replace '/','\') } |
  Where-Object Length -gt 260 |
  Export-Csv .\long-paths.csv -NoTypeInformation

Why it does not fall over: -PageSize 2000 pages through the list under the view threshold, and requesting only FileRef keeps memory small. Run it per library; loop Get-PnPList for a whole site.

That is the 260-character Windows check, which is the one most people need. It is not the whole picture: Office stops at 259, the Mac limit is 255 bytes per segment rather than characters, the sync client has its own 520 ceiling, and every one of those needs the path decoded and measured differently. Checking all of them per client profile is the part we built the tool for.

Which folder to rename

A list of 3,000 over-limit files is not actionable. What is actionable is: renaming folder X saves N characters for M files. Group the CSV by top-level folder and count; the folder at the top is the one to shorten. Most libraries have two or three deep, verbosely-named folders responsible for the majority of failures, and renaming those is a five-minute fix that a 3,000-row spreadsheet hides — which is why the scan should rank them for you.

Before a migration specifically

Run the scan against the source (a file share scan with the same arithmetic works: prefix + relative path) so you can shorten folders before the move, when renames are cheap and nothing is synced yet.
Watch segment length (255) separately; migration tools truncate or fail on it regardless of total path.
Non-Latin and accented names: on macOS the 255 is bytes, so a 120-character Cyrillic folder name can fail.

The scan as a page

SyncHealth365 does this scan from inside the library, read-only: pick a client profile (SharePoint/OneDrive cloud, OneDrive on Windows, Windows classic apps without long-path support, OneDrive on macOS), see which items will break and which are at risk, and see which folder rename fixes the most paths. It is free, it uses SharePoint's own paged listing endpoint, and the limits it checks against are Microsoft's documented figures with the source linked per limit.