Microsoft 365 path length: 260 vs 400 characters

Short answer

Microsoft 365 path length involves both service and local application limits: SharePoint and OneDrive allow 400 characters in a decoded service path. Windows tools that use MAX_PATH can have a smaller 260-character limit, including the terminating null. Design filenames for the smaller budget, which DNM checks for files you bring into the app and review before saving.

A file can fit the Microsoft 365 service limit and still fail in a local application. Check the decoded service path and the complete local path, including the OneDrive root. The limits that matter depend on the applications and operations in your workflow.

What is the path-length limit in Microsoft 365?

Windows MAX_PATH is 260 characters, including the terminating null. For a conventional path, that leaves up to 259 visible characters, including the drive, folders, filename and extension. Some Windows APIs support longer paths. Starting with Windows 10 version 1607, many common file operations can opt out of MAX_PATH when both the system setting and the application support long paths.

SharePoint Online and OneDrive allow up to 400 characters in the full decoded service path, including the filename, as Microsoft documents. A space encoded as %20 in a URL counts as one decoded character, not three. Meeting that limit alone does not guarantee that every local application can open the file.

Microsoft also documents a 255-character limit for an individual file or folder name and a 520-character limit for the combined OneDrive root and relative local path. Those sync limits do not override a lower limit in another application.

A workflow can span both cloud storage and local applications. Plan for the applicable limits at each step, and leave room for changes in the destination path.

A path that fits comfortably

C:\Users\jsmith\OneDrive - Acme Corp\: 37 chars, the base sync root.
Departments\Marketing\2026\Q2\Campaigns\: 40 chars of folder hierarchy.
Spring-Launch-Campaign-Final-Approved-v3.pptx: 45 chars of filename.
Total: 122 characters, well under the wall.

An illustrative path that is one rename from the wall

C:\Users\r.okafor\OneDrive - Harbourview Strata Inc\: 52 chars.
Shared with Everyone\Operations\2026\Quarterly Reviews\Q2\: 58 chars.
Board Materials\Approved Final Versions\Reviewed by Legal\: 58 chars.
2026-Q2-Board-Materials-Reviewed-FINAL-USEME-Reviewed-Legal-Approved-v3.pptx: 76 chars.
Total: 244 characters. Adding more than 15 characters would exceed the conventional 259-visible-character MAX_PATH budget.

Notice the 52-character root. A work or school account's OneDrive folder carries the organization name, so it spends more of the budget than a personal OneDrive folder before your first subfolder. Microsoft's own worked example uses “OneDrive - Contoso” for the same reason.

Why does the same file open in one app and fail in another?

LongPathsEnabled is only one part of Windows long-path support. An application must also support the relevant long-path behavior. Windows file-system APIs and the shell can behave differently, so a file that one operation can create may still be inaccessible through another.

Do not assume File Explorer, Office, a migration tool or a backup utility will handle the same long path in the same way. Behavior depends on the version, operation and configuration. Check the target tools, test representative files, and review error and migration reports. See the Microsoft 365 file-readiness guidance before moving a large collection.

Include the applications your colleagues actually use in the test. Successful sync alone does not prove that every downstream tool can open the same path.

How do I find the long paths already on my drive?

If you suspect path-length trouble, first confirm that $env:OneDrive contains the intended existing OneDrive folder. Do not run this scan with an empty or unintended root. Then this read-only PowerShell command lists long paths beneath that folder:

Get-ChildItem -Path $env:OneDrive -Recurse -File | Where-Object { $_.FullName.Length -gt 240 } | Select-Object FullName, @{N='Length';E={$_.FullName.Length}} | Sort-Object Length -Descending

A 240-character review threshold leaves room below the conventional MAX_PATH limit. It identifies paths to investigate, not confirmed sync failures. Review any enumeration errors as well: an inaccessible folder may not appear in the results.

How to design filenames that clear both limits

Use meaningful filename fields without repeating the entire folder hierarchy. Shorter names leave more room, but only a check of the complete path establishes whether the example fits.

Budget for the conservative ceiling. For a complete local prefix of 150 characters, including separators, an 80-character filename produces a 230-character path. That leaves 29 visible characters below a conventional 259-character budget. A deeper destination or a different tool can change the result, so check the complete path.
Review unnecessary nesting. Folder count alone does not determine length. Shorten repetitive folders where practical without removing structure your team needs.
Check the intended path before saving. DNM checks paths for files you bring into the app, with warnings and validation for Windows and Microsoft 365 contexts. It does not intercept every Windows Save dialog or validate a later move performed by another tool. This is DNM's own path-length check, not a Microsoft certification.

A short, consistent filename doubles as a naming-standard win, and the 12-character rule for file names that scale is a quick way to keep each element tight. A name like Acme-Corp_20260424_Board-Minutes-Q2_RPT.docx follows the DNM naming standard (in the General standard: Division, then date, then description, then a short type code; some standards put the type code before the description) and illustrates a compact structure. It still needs checking in its full destination path. You can preview names in the naming convention generator before committing to them.

Does the LongPathsEnabled registry flag fix this?

No. LongPathsEnabled does not change Microsoft 365 service limits and does not make every Windows application long-path aware. Use it only as part of a tested workflow, not as a substitute for checking destination paths and application support.

What this means for your workflow

Path-length sync failures can cause rework, but the impact depends on the workflow. Our Cost of File Chaos calculator models search time from your estimates rather than measuring sync-failure costs. To review naming and path checks in your own workflow, you can try DNM free for 14 days, no card required, and test the checks on files you review and save through DNM.

Migrating to Microsoft 365? Work through the full Microsoft 365 migration checklist.

Common questions

Does LongPathsEnabled remove every path limit?

No. The application must support the relevant long-path behavior, and Microsoft 365 service and sync limits still apply.

Does the PowerShell scan prove that a file will fail?

No. Its 240-character threshold identifies paths to review. Check the destination and applications, and inspect any enumeration errors.

Does DNM check a later move made outside the app?

No. Review the destination path again if another tool moves the file after DNM has processed it.