Issues regarding maximum URL length RRS feed

  • Question

  • If I've understood this correctly, there's a maximum URL (as opposed to QueryString) length of 255 (or 260?) chars for SharePoint. How exactly does that affect opening a nested-folder-document in say Word or Excel? And is the limit also there for the explorer view? 255 chars isn't a whole lot for a directory and filename structure, so if it also affects the explorer view; is there a way around it?

    Just now I tried creating a dummy structure in a some subsite document library. When my entire QueryString reached 800-1000 chars, it seems the entire SharePoint site managed to crash. Any ideas on why that happens?
    Tuesday, November 27, 2007 10:11 AM

All replies

  • Hi einaros,
    SharePoint limits URL length because all relative URL links are stored in the clear forms on the SharePoint content DB and offen this links are used as primary keys to link one table with another. Fields which are used to store these links (for instance tp_DirName from the AllUserData table) allow to store only 256 characters.
    Also SharePoint has the limitation of Leaf Name length (it's for instance DocLib name, file name and etc) because tp_LeafName field from AllUserData table could store only 128 characters.

    I don't know why SharePoint limits these lengths but it's restricted on the database level.

    Therefore you could not create anything with URL that's longer than 255 characters.

    May be I'm wrong and I hope that anybody could explain it more accurate.

    Wednesday, November 28, 2007 9:43 AM
  • Wouldn't these database field limits also affect the maximum number of nested directories in a document library -- even disregarding an url length limit as such?

    It strikes me as odd that a limit such as 256 chars is introduced "in this day and age".

    I'd really appreciate a deep dive into this, as well as common workarounds (if any).
    Wednesday, November 28, 2007 10:36 AM
  • No, maximum number of subfolders is not affected by these limitation. You could find info about all "count&size" limitations here:

    According to the database structure folder from the document library is like "item" but with another ContentType. So you could create any (< 2 millions) items count BUT for the optimum performance item (and I think folder) count on the one level should be  < 2000.

    Another Microsoft doc (http://technet2.microsoft.com/Office/en-us/library/6f03049f-5bfe-4807-b609-0e2d4a9ec3b51033.mspx) says that "The maximum number of items supported in a list with recursive folders is 5 million items"

    What is about workaround? What do you need?

    Wednesday, November 28, 2007 10:54 AM
  • Well the problem, as mentioned in the inital post, is that the document libraries do not accept paths exceeding 260 chars. If you create a doclib with a series of nested directories, it'll eventually throw an error at you such as

    The specified file or folder name is too long. The URL path for all files and folders must be 260 characters or less (and no more than 128 characters for any single file or folder name in the URL). Please type a shorter file or folder name.

    This also affects opening documents in e.g. word, as well as browsing with Explorer View.
    Wednesday, November 28, 2007 11:52 AM
  • hmm, I think that you need to cut your doclib subfolder names. I don't see another workaround.
    Wednesday, November 28, 2007 12:28 PM
  • That's the part that seems odd to me. 260 chars is just ridiculously low for a document library with a hierarchy.
    Wednesday, November 28, 2007 12:52 PM
  • Agree. But it's fact Smile
    Wednesday, November 28, 2007 1:00 PM
  • I think I'll have to keep bumping this thread until someone from the SP team can make a comment on the matter.
    Wednesday, November 28, 2007 1:03 PM
  • I think that wouldbe good Idea to do but I don't think that Microsoft Product Team does care about such things they would say that willbe fixed in next release of SharePoint.

    Or if somebody is kind enough will say that willbe fixed in Next Service Pack.
    Saturday, March 8, 2008 10:45 PM
  • When your folder url is formatted to read in this form :

    http://server.com/site/subsite/subsubsite/Team Documents/foldername


    instead of in this form : 



    then check the string length and observe the following limitations:

    http://support.microsoft.com/kb/923906 explains the problem.

    In IE6 the limit for a folder path is 100 characters, in IE7 – the limit is 260.


    This is the limit for the non url-encoded string, in the shorter 'prettier' format.  Otherwise this can confound you if you are counting url characters and trying to figure the breaking length. :-)



    Also, although the length is claimed to be 260 characters, when trying to use the document library 'send to' functionality, or creating a new SharePoint link, the url input text boxes do not accept more than 255 characters, so one would do wisely to keep them shorter than 256 characters.


    Wednesday, March 26, 2008 8:21 PM
  • Hi there,

    Microsoft has published a hotfix for fixing lenght of the URL limitation


    Thank you,
    Friday, October 3, 2008 4:40 PM
  • Hi MuzaffarA,

    I don't see anything about URL limitation on that Hotfix description.

    I'm having tha same issue. I have a MOSS farm where our team has deployed an automated solution that uploads documents and creates document libraries that could me nested in several levels. We're having the HUGE problem that those documents cannot be searched nor found via search site.

    I've seen a couple workarounds for this on the web related to create an alternate virtual directory on IIS that could redirect to the full-very-long URL (http://fmuntean.wordpress.com/2008/05/12/tiny-url-in-sharepoint/) but as far as I understand this article implies creating a virtual directory for each and every document uploaded and that is just imposible.

    Any idea? I think the redirection thing is a good concept but I'm thinking how to apply that to hundred of documents automatically uploaded on a daily basis.


    Marcel Jeanneau
    Microsoft Peru
    Thursday, June 4, 2009 11:25 PM
  • Hi

    Is the url Limitation issue has been fixed in MOSS 2007.

    Any Idea?

    Tuesday, November 3, 2009 1:38 PM
  • As of now No.

    Neeraj Rai
    Wednesday, November 11, 2009 9:47 AM
  • Give me a break. Why microsoft product team is not working on this basic issue.
    If some one is migrating there file structure this is one the biggest stumbling block.
    Wednesday, March 10, 2010 4:03 PM
  • IMHO there is nothing wrong here that needs fixing!

    The reality is this is a web application/site; its not file store and I think should never be treated as such.  Your users need to learn to use filters and create Views to differentiate items in the List, not folders.  I really wish that Microsoft had never introduced the folder metaphor (after all its not a real folder, its just a View) or the Explore View with drag and drop into SPS 2003 or kept it in later versions - ho hum! :-(

    So to repeat; this is not file store and should not be used like it is, as it limits its usefulness as a collaboration tool. So I wouldn't hold your breath waiting for Microsoft to 'fix' it.



    Wednesday, July 14, 2010 4:29 PM
  • You are correct GarrathE. The problem is that users are creating folders inside of SharePoint.. a hold back from the days when they stored their files in a File System and organized with folders. The solution is to train users properly.
    Friday, January 14, 2011 10:45 AM
  • One note here not mentioned directly in this thread (I did not read all the URL links) is that when a user checks out a docuemnt to edit it, the default location will be a folder of the same path structure.  And don't forget the URL is also part of that path...look at your Window dir for your SharePoint Drafts folder for example.

    NTFS has a limit on file system length of (not 100% sure) right about that same 256 / 260 size.

    I have seen this "bite" users when trying to have long folder names and long file names and then attempting to save that structure as a template.  The folder structure which had to also include some temp chars for SharePoint use, exceeded the 256/260 length and the template save failed.

    There is a fairly simple SharePoint given workaround.

    There are 2 names used by SharePoint - the File Name  (what is stored in the DB and on Disk) and the Friendly Name / Display Name.

    The first entry should be as short and compact as possible, this is where this thread detail matters...

    The second name - the user friendly display name, can be of any length and structure desired, as this is not what is stored / used by the disk system.

    So something like a document or folder by the desired name of "Architecuture Recommendations for SharePoint 2010 Production"  will be fine for the Display name, but should be stored as "2010Arch" or some such similarly short name.

    Likewise you can manipulate a folder by naming a folder such as "Current Architecture Recommendations" to "Arch" and then edit the properties of the folder to change the Title and Description to something much longer.

    SharePoint will "store" the original name given at the time of folder creation and use this "internally" but will gladly display any string to the user.

    Hope that makes some sense and helps you out...

    Thanks, Eric S. Pcubed

    Monday, June 18, 2012 5:49 PM
  • Is it still 256 in SP 2010?
    Monday, October 22, 2012 10:22 PM
  • not agree.

    how do you manage security access ?  You can not set security on list column as you can do on folder.

    Thursday, September 26, 2013 9:52 PM
  • If SharePoint limits the amount of characters for a URL, that is one thing, but it is not consistent.  We are having this issue with a document library we've used for over a year and just yesterday (8/1/16), we started having issues saving files into the intended folder within the library.  But the probably is it is not consistent, I resaved a file using dashes instead of spaces and was able to save the file into the intended folder, but another user tried the same thing (and even shortened the file name) and it did not work for her.  The file I saved was more than 256 characters and that one saved.  So it doesn't make any sense.
    Tuesday, August 2, 2016 1:10 PM