I have a sharepoint app with multiple .aspx pages. On different pages I push and pull from sharepoint lists and I would like to send emails. These require me knowing hostUrl and appWebUrl.

I would like to get hostUrl and appWebUrl using the following code, which I have found on multiple tutorials:

var appWebUrl = decodeURIComponent(getQueryStringParameter('SPAppWebUrl'));
var hostUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));

However, those only work the very first time the page is loaded, and only work on Default.apsx.

>> getQueryStringParameter('SPAppWebUrl');

>> getQueryStringParameter('SPHostUrl');

If I navigate from Default.apsx to Page2.apsx, or simply load to Page2.aspx initially, those lines return the following error:

>> getQueryStringParameter('SPAppWebUrl');
Uncaught TypeError: Cannot read property 'split' of undefined

>> getQueryStringParameter('SPHostUrl');
Uncaught TypeError: Cannot read property 'split' of undefined

This is because getQueryStringParameter (seen here) uses document.URL which changes significantly after navigating to a different page.

>> console.log(document.URL) // before

>> console.log(document.URL) // after

For hostUrl I think I could do:

>> "mycompany.sharepoint.com" + SP.ClientContext.get_current().get_url();

But that doesn't work for appWebUrl because I need the number/letter code in the url to send emails.


Why doesn't getQueryStringParameter work on different pages and what's another method of retrieving these urls that would work accross different pages?

Thanks in advance.

4 Answers 4


I think I found a solution for appWebUrl. ssdar's answer gave me the same problem as I initially had with loading different pages, but another answer in the thread they linked to contained an answer that led me to the right path.

Instead of:

var appWebUrl = decodeURIComponent(getQueryStringParameter('SPAppWebUrl'));
var hostUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));

These work in all situations, regardless of the page.

var appWebUrl = window.location.protocol + "//" + window.location.host 
                + _spPageContextInfo.webServerRelativeUrl;

var hostUrl = _spPageContextInfo.siteAbsoluteUrl;

Does anyone know what the difference is between the two, and why someone would use the former rather than the later?


So, you have the query string parameters available to grab from your URL and you are trying ways to do that. I suggest you look at the function GetURLKeyValue. It does exactly that. It is an OOTB SharePoint JavaScript function that is readily available on any page, SP 2010, 2013, without needing any library reference.

For your case, the below function should return the query string parameter SPAppWebUrl in the browser url, and returns the decoded value.

GetURLKeyValue('SPAppWebUrl', false) 

You can also specify whether you want to return the encoded or the decoded value.

This is the schema of the function:

GetURLKeyValue(NameOfTheKey, BoolNoDecode, url, BoolCaseInsensitive)

And out of curiosity, why do you have both of the webUrl and HostUrl being passed around in the URL, as could easily calculate them in your code (JS or Server side) anytime you want them.

You can look at the discussion here and see if this is something you might want.

  • The accepted answer in your link actually is what ended up working the best for me with some minor adjustments, so thanks a lot for directing me there. Commented Mar 4, 2015 at 19:40
  • Happy to help, can you please mark the answer?
    – ssdar
    Commented Mar 4, 2015 at 19:48

Yes, as you said SPHostUrl is available as query string parameter for the first time the app is accessed from the host web. But it's no longer available if we go on access any other pages.

The possible approach is to save the SPHostUrl somewhere in cookie/session. So that the same can be used further. I found an Article on the same with coding snippet and detailed information on how to deal with this.

Note: Though SPAppWebUrl is not available, we can get it from the current web. context.

  • Or localstorage
    – eirikb
    Commented Mar 4, 2015 at 21:08

You are halfway to answering your own question! :)

As you noticed, the URLs are quite different, and the difference is the query string. The first part of a URL usually points to a page (like http://my/site/app/pages/default.aspx), and the query string is everything that comes after the ? character immediately following the page (like http://my/site/app/pages/default.aspx?key=value&otherKey=otherValue). Query strings are not limited to SharePoint, but can be used by any web application to pass information between pages by inserting that information into the URL.

So in the case of your Page2.aspx, the reason getQueryStringParameter fails is because there is no query string. As you can see in your console.log, there is nothing after /Page2.aspx.

What's happening is that when you first enter your app from your main host site, SharePoint is automatically adding the query string. In your app, wherever you have your link to Page2.aspx, you are not adding a query string. (Query strings do not get passed on by default.)

So the way I see it, there are a couple ways you can deal with the situation:

1 - On Default.aspx, retrieve the values you want, and in JavaScript, intercept the clicks on links to other pages so that you can insert a query string into the URL and pass the values to the next page.

2 - Add a new list to your app web to store the values. When Default.aspx gets loaded, check the list to see if the values are there. If they are not (the first time the page is loaded), get the values you want from the query string and store them on the list. Then, the rest of your pages can get the values from that list instead of from a (nonexistent) query string.

EDIT to add:

As @Murali Krishna Golla pointed out, you could also store the values in a cookie.

The point is, in general, your solution to this problem is to get the values you want when Default.aspx is loaded and has a valid query string, and figure out some way of persisting those values so you can retrieve them from the other pages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.