ASP.NET session variables, cookies, query string parameters, etc.
Part two of a five-part series of blogs

There is a range of techniques for remembering information in ASP.NET across pages and even sessions, including session variables, cookies, query string parameters and crosspage postback. This blog explains how to use each of these techniques, together with the pros and cons of each.

  1. Remembering State between Pages
  2. Passing Data by Query String in the URL (this blog)
  3. Passing Data using Session Variables
  4. Using Cookies to Remember Things
  5. Cross-Page Postback

This page is part of an online tutorial in ASP.NET.  We're also happy to train you in person in ASP.NET!

Posted by Andy Brown on 16 October 2012

You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.

Passing Data by Query String in the URL

What a Query String Is and Does

A URL is simply a web site address (it stands for Uniform Resource Locator). At the time of writing, this is the URL which appears in a web browser when you go to Dell's UK site and click on the Windows 8 icon:

The Dell Windows 8 URL

This appears in the address bar when you click on a particular icon.

The URL tells you go to the website, but adds on the following additional query string arguments:

Argument Value Guessed meaning
c uk Country (United Kingdom)
cs ukdhs1 No idea!
l en Language (English)
ref hpt4 No idea!
s dhs No idea!

You can pass any information you like from one web page to another in this way, provided that you use & to separate the name-value pairs.

The above method illustrates the strength and weakness of this approach.  On the one hand, it's transparent and easy to understand; but on the other, anyone can change the values of parameters to try to hack into a website.  This is why you should avoid passing record ids in a query string.

Creating the URL in Code

You can build up a website address using code, then use response.redirect to transfer to it.  The C# and VB code is similar.  Here's the C# code:

#region Query string method

protected void btnQueryString_Click(object sender, EventArgs e)



// need to add arguments to query string (assume

// that they were entered OK)

string Contains = txtContains.Text;

string Status = txtStatus.Text;


// build up query string

string UrlString = "frmTaskListCs.aspx?m=" +



if (Contains.Length > 0) { UrlString += "&c=" + Contains; }

if (Status.Length > 0) { UrlString += "&s=" + Status; }


// go to this URL





Here's the corresponding VB method:

#Region "Query string method"

Protected Sub btnQueryString_Click(sender As Object,

e As System.EventArgs) Handles btnQueryString.Click


'need to add arguments to query string (assume

'that they were entered OK)

Dim Contains As String = txtContains.Text

Dim Status As String = txtStatus.Text


'build up query string

Dim UrlString As String = "frmTaskListVb.aspx?m=" & _


If Contains.Length > 0 Then UrlString &= "&c=" & Contains

If Status.Length > 0 Then UrlString &= "&s=" & Status


'go to this URL



End Sub

#End Region

Thus if you enter search terms as shown below and click on the button highlighted:

Search form filled in

Assume that you fill in the form as shown below and click on the button to pass the data in the URL.


Then the variable UrlString will hold a value like the following (where the file name is frmTaskListCs or frmTaskListVb, depending on the code used):


Here there are 3 arguments set:

Argument Value What it means
m 1 We're using the first method of the enumeration (ie transferring data using the URL query string).
c something The value of the first text box (what the to-do item must contain).
s ongoing The value of the second text box (the to-do item statuts).

Picking Up on the Values Passed in the Query String

You can use Request.QueryString to pick up on these arguments passed in the target file.  Here's the code attached to the frmTaskList page's load event - first the C# code:

protected void Page_Load(object sender, EventArgs e)


if (!Page.IsPostBack) {


// look at how info being passed

clsShared.TransferMethod TransferMethod;

try {

int TransferMethodId = Convert.ToInt32(Request.QueryString["m"]);

TransferMethod = (clsShared.TransferMethod)TransferMethodId;

} catch {

TransferMethod = clsShared.TransferMethod.NotSet;



string Contains;

string Status;


switch (TransferMethod) {

case clsShared.TransferMethod.QueryString:

// if (passed info in query string, try to get it

try {

Contains = Convert.ToString(Request.QueryString["c"]);

Status = Convert.ToString(Request.QueryString["s"]);

} catch {

Contains = "Not passed";

Status = "Not passed";


litContains.Text = Contains;

litStatus.Text = Status;





Now the VB equivalent (I've missed out a lot of irrelevant code in both cases):

Protected Sub Page_Load(sender As Object,

e As System.EventArgs) Handles Me.Load


If Not Page.IsPostBack Then


'look at how info being passed

Dim TransferMethod As clsShared.TransferMethod


Dim TransferMethodId As Integer =


TransferMethod = CType(TransferMethodId,


Catch ex As Exception

TransferMethod = clsShared.TransferMethod.NotSet

End Try


Select Case TransferMethod

Case clsShared.TransferMethod.QueryString


'if passed info in query string, try to get it

Dim Contains As String

Dim Status As String



Contains = Convert.ToString(Request.QueryString("c"))

Status = Convert.ToString(Request.QueryString("s"))

Catch ex As Exception

Contains = "Not passed"

Status = "Not passed"

End Try


litContains.Text = Contains

litStatus.Text = Status


End Select

End If

End Sub

In both cases, we detect the value of each query string parameter passed in (note that it doesn't matter what order they are specified).

Note that you can use Request.QueryString on its own to get the entire URL set.

HTML Encoding

One problem with the above approach is that it doesn't work well for HTML escape characters.  Consider the following search form:

Search form containing &

If you run this search anything after the M will be ignored.


The obvious reason for this is that characters like & and % can not be used in a query string without first encoding them.  You can do this using Server.UrlEncode, whether in C#:

if (Contains.Length > 0) { UrlString += "&c=" +

Server.UrlEncode(Contains); }

if (Status.Length > 0) { UrlString += "&s=" +

Server.UrlEncode(Status); }

Or in VB:

If Contains.Length > 0 Then UrlString &= _

"&c=" & Server.UrlEncode(Contains)

If Status.Length > 0 Then UrlString &= _

"&s=" & Server.UrlEncode(Status)

If you then search for M&S your query string will look like this:

http:// ....aspx?m=1&c=M%26S

Here the character & is represented by its corresponding HTML escape character sequence %26, and everything should work OK!

Disadvantages of Using Query String Parameters

Passing data in query strings has a few potential problems:

Problem Details
Privacy You can't use a query string to pass sensitive information, as anyone can see it. In general, this will include any id field.
Limited length Query strings aren't infinite! The exact length depends on the browser you're using and the URL path length, but you should keep query string arguments short (that's why we used c and s for our example).
Changed URLs What will happen if someone using your website accidentally or maliciously changes a URL? If they miss out one of the arguments, or change the value for one of them, will your site still work?
Search engine optimisation No one is sure whether passing arguments in query strings affects how search engines like Google rate your website - which is a good argument for avoiding them in pages which you want to feature highly in search engine algorithms.

Note that there are ways to hide query string parameters, but they're all complicated, and I don't particularly like them!

Conclusion and Recommendation

Passing parameters in a query string is the simplest method in ASP.NET.  Use it for internal intranet systems and for public websites where the data being passed isn't confidential and search engine optimisation isn't a priority.  However, you should always be aware of - and code for - people submitting amended URLs, either maliciously or accidentally.

This blog has 0 threads Add post