Querystring parameters you should not use in your SharePoint application

[Updated on February 22nd, 2010 - adding additional values for WSS 4.0]

Today I have been working on a support case where customer experienced exceptions in sharepoint when passing in specific query string parameters which are evaluated by his web parts. The URL looked similar to this:


The problem here is caused by the fact that the customer used a reserved query string parameter. When creating the SPContext object SharePoint evaluates the following query string parameters if provided:

  • FeatureId

  • ListTemplate

  • List

  • ID

  • VersionNo

  • ContentTypeId

  • RootFolder

  • View

  • FolderCTID

  • Mode

  • Type

With WSS 4.0 the following query string parameters need to be added to the list:

  • PageVersion

  • IsDlg

  • Title

  • _V3List_

To ensure that the creation of the SPContext object does not fail your application should ensure that your query string parameters are different from those listed above.

Comments (15)

  1. Vertigo Hopes says:

    I noticed that when I used the ID parameter in the query string, it would work for numbers but not letters. ?ID=1234 would render correctly, but ?ID=123A causes the page to crash. Any ideas? I'm using SharePoint 2010 and a query string filter web part to filter a document library web part.

  2. Hi Vertigo,

    as indicated these parameters are reserved and internally used for a special purpose.

    E.g. the ID parameter is undergoing a string-to-int conversion to map it to a list item ID.

    If this parameter now contain non-numeric values this string-to-int conversion will fail and you will get an exception.

    Using any of these parameters in your code can lead to unpredictable results.



  3. Edward Joell says:

    Truly unpredictable.  We are used the parameter ID in four or five querystrings sometimes as the first parameter other times as the second or third parameter.  We had an issue with only one usage where the any user without Site Collection Admin rights would get an Access Denied error thrown on attempting to open that page. But when the parameter name was changed to ListItemId then the page worked as designed.  However none of the other pages with that parameter in the call to open the window responded in that fashion. Truly a model of SharePoint's consistency

  4. Dr Adrian Colquhoun says:

    Is there a definitive list anywhere of the query string parameters that we are allowed to use?

  5. Hi Adrian,

    that is impossible as there is an endless list of allowed query string parameters.



  6. Brahmam says:

    Is there a definitive list anywhere of the query string parameters that we are allowed to use?

  7. Hi Braham,

    I doubt that there is enough disk space available world wide to store the list of all allowed query string parameter names.



  8. jeremy says:

    While the question is silly, neither answer is productive.

    The key to finding a solution is to recognize that the reserved list must be avoided as the name of the Querystring parameter, yet you are still able to filter against the ID column, for example.

    Simply use a "friendly" name for the actual Querystring parameter. If your list is Customers and you want to filter your by the ID field, name your Querystring parameter CustomerId or cid or … (anything but a name on the reserved word list).

    In the configuration of your connection, use ID in the Consumer Field Name. Using this approach, the expected results are achieved consistently.

  9. Io says:

    Mortacci tuaaa!

    Yes, but as one reads the parameter from querystring?

  10. Hi Io,

    you can read them – but you should not set these query string parameters.



  11. What i understand that even for adding a new query string parm, we should used some different name other than which are mentioned in the post

  12. Hi Mohammad, your understanding is correct.

  13. psmith1117@hotmail.com says:

    This help me with a SharePoint 2013 issue. I was passing "Title" as a parameter in the url. I changed it to JobTitle and everything works!

  14. Daniel Balos says:

    If you pass a parameter ID, you should also pass corresponding ListID…. Then it does recognize it as legitimate query string, even if you do not care about the ListId…
    Quite late in the discussion but perhaps helps someone

Skip to main content